Fix rnpkeys dll sideloading vulnerability of rnp.dll

[RootLUG]

Hello,
the binary rnpkeys.exe as distributed with Thunderbird is currently being used in advanced threat actor operations by leveraging a DLL sideloading vulnerability for rnp.dll to bypass security scans and possibly EDR systems. The DLL lookup path should be fixed to not allow the loading of dll from arbitrary location from which the program is placed/executed or to verify the chain of trust for dlls to be also signed with same CA as the main rnpkeys before they are being loaded.

The vulnerability is abused by replacing the legitimate rnp.dll in the same directory as rnpkeys.exe with malicious implant which is then loaded without any verification by rnpkeys that is digitally signed (with valid legit cert for Thunderbird). On system level this would then appears as a legitimate trusted process which is further used to bypass security defences once the malicious implant is loaded and being executed by rnpkeys.exe

[ronaldtse]

Thank you for this report - confirmed and addressed in #2478.

What landed:

• rnp / rnpkeys on Windows now verify at startup that every module loaded from the executable's directory has a valid Authenticode signature, but only when the executable itself is signed (unsigned development builds are unaffected). A swapped, unsigned rnp.dll makes the tool abort with a clear error instead of running on.
• Because the Windows loader maps the DLLs before main(), a startup check can detect-and-abort but cannot fully prevent the replaced module's initialization code from running. For signed distributions we now also document that building the tools with static librnp (BUILD_SHARED_LIBS=OFF) removes the rnp.dll side-loading vector entirely - that is the recommended configuration for distributors such as Thunderbird.
• Thunderbird builds rnp from its own third_party/rnp moz.build (not rnp's CMake), so the vendored build needs the new src/common/dll-verify.cpp added to the CLI programs plus crypt32/wintrust on the link line; we'll follow up on the comm-central side once this merges.

[ronaldtse]

@kaie @tomrittervg - looping you in since the complete fix for this is distributor-side.

Where things stand:

rnp side (defense-in-depth, PR #2478): rnp/rnpkeys on Windows now verify at startup that every module loaded from the executable's directory carries a valid Authenticode signature, but only when the executable itself is signed (unsigned dev builds are unaffected). An unsigned swapped rnp.dll makes the tool abort with a clear error. To be explicit about the limits: the loader maps the DLLs before main(), so this detects-and-aborts but cannot prevent the replaced module's DllMain from running - it raises the bar for implants that need the host process to keep functioning, it does not close the window.

Complete closure is on the Thunderbird side, since the abused trust is Mozilla's signature and the install layout is a distribution choice:

1. Preferred: build the vendored CLI tools with static librnp (no rnp.dll sibling at all). rnp fully supports static CLI builds (BUILD_SHARED_LIBS=OFF in our CMake; in the comm-central moz.build that means linking the static variant instead of SharedLibrary("rnp") for the two Program()s).
2. If the shared layout stays: when re-vendoring rnp with cli: verify signatures of side-loadable DLLs on Windows (#2411) #2478, add src/common/dll-verify.cpp to the src/rnp / src/rnpkeys programs and link crypt32 + wintrust on WINNT - then signed Thunderbird builds get the startup check. MSVC/clang-cl and mingw-w64 both compile it; it has no rnp config.h dependency by design.
3. Independent of both: consider /DEPENDENTLOADFLAG / directory ACL hardening for signed install dirs, as with the earlier side-loading reports in other Thunderbird components.

Happy to file the comm-central bug with the exact moz.build patch once #2478 merges - just say the word.

[kaie]

Thanks for the ping. I think using static linking would result in an undesirable size increase for the Thunderbird distribution.
I think we should explore suggestions 2 and 3.

[kaie]

Thunderbird currently distributes the rnp-cli.exe and rnpkeys.exe only for convenience purposes.

The presence of those executables is not necessary for the operation of the Thunderbird software.

Thunderbird could stop distributing those executable at all. That would be the simplest fix.

I assume that on installing an updated Thunderbird distribution, that no longer contains these executables, the exe files from the previous distribution would get automatically removed?

Or, in contrast, would releasing fixed executables be the only way to guarantee that those executables do not remain on systems that previously used older Thunderbird versions?

[ronaldtse]

@kaie answers to both points, plus an update that removes most of the friction:

Your update question: yes - files dropped from the distribution are removed automatically by the standard updater. Complete updates remove everything listed in the old installation's precomplete manifest (generated at package time, it enumerates every shipped file/dir precisely so the updater can "uninstall" before applying the complete MAR), and partial MARs encode removals explicitly since they are built per version pair. So dropping rnp-cli.exe/rnpkeys.exe cleans them from user systems on their next update through AUS; shipping fixed executables would not be required for the removal itself. The residual population is only users who stay on old versions - which fixed interim exes wouldn't help either, since those users don't update.

Suggestion 2, now with zero changes on your side: we reworked #2478 so that Thunderbird needs no moz.build or link changes at all:

• the check lives in fficli.cpp, a file your third_party/rnp/src/rnp/moz.build and src/rnpkeys/moz.build already compile into both programs - a plain re-vendor brings it in;
• WinVerifyTrust is resolved at runtime from System32, so there is no new crypt32/wintrust link dependency;
• to avoid policing Thunderbird's whole install directory (~100 DLLs, and seconds of signature checks per run), it verifies only the modules from the executable's own directory that are in its import chain - effectively rnp.dll - and only when the executable itself is signed. Unsigned/dev builds and CI are unaffected.

Combined with your option of dropping the convenience executables (which the updater then cleans up on users' next update), that covers both the deployed fleet and future distributions. Suggestion 3 (/DEPENDENTLOADFLAG) we should drop, with apologies for suggesting it: LOAD_LIBRARY_SEARCH_SYSTEM32 for dependent loads would break loading rnp.dll from the application directory entirely, so it is not applicable while the DLL stays next to the exe.

[kaie]

Thanks Ronald for the detailed explanation. No worries regarding option 3. [edited: typo]

To deploy the fix to stable Thunderbird releases, I think it would be preferable to avoid the new complexity of option 2. So as the initial hotfix, it might be best to simply stop shipping the executables.

After that is done, once we are able to pick up your fixes, we could start shipping the executables again.

I suggest to investigate whether the macOS platform is similarly affected and whether it would also require a fix, prior to shipping the executables again.

[ronaldtse]

@kaie we completed the macOS investigation you suggested - good news: macOS is already protected by your current signing configuration, no rnp-side fix is needed. Evidence from the current Thunderbird release (downloaded today):

• Thunderbird.app/Contents/MacOS/rnpkeys and rnp-cli are signed with the hardened runtime (flags 0x10000(runtime), Team ID 43AQ936H96) and carry no entitlements - so library validation is enforced. They load @rpath/librnp.dylib (rpaths $ORIGIN / @executable_path), i.e. mechanically the same side-loading surface as on Windows.
• Verified empirically: replacing librnp.dylib in a writable copy with an ad-hoc signed dylib (an attacker-style replacement) makes the process abort at load, before main(): dyld: Library not loaded: @rpath/librnp.dylib ... code signature ... not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs. A replacement signed by Mozilla would still load - but then it is not an attacker replacement.
• For contrast, the thunderbird main binary itself carries com.apple.security.cs.disable-library-validation (needed for add-ons), so the residual macOS exposure is the main application process, not the rnp tools.

So the only macOS-side requirement going forward: keep signing the bundled rnp executables without disable-library-validation (and DYLD_* env injection is already stripped for hardened-runtime binaries). We have documented this in #2478 (docs/packaging.adoc) so distributors know the required configuration.

That makes the overall plan clean: drop the executables as the hotfix (the updater removes them from user systems on the next update, as discussed), and re-vendor #2478 later to resume shipping - Windows picks up the runtime check with zero build changes, macOS is covered by library validation as long as the entitlements stay off.