Plugin trust chain: unsigned DLLs, hash-only verification, and a writable plugin directory

[Firefly0619sec]

Where this comes from: an independent audit of Notepad++ 8.9.8.1 (x64), source + binary verification. Not a demand - a description of the current trust chain, so users can decide how much they trust it.

What the current chain validates

For third-party plugins installed through Plugins Admin, Notepad++ verifies that the downloaded zip’s hash matches the hash recorded in the plugin list. As Coises explained in the other thread: “That is all that is done”, and the maintainer does not vet plugin contents (apart from mimeTools / NppConverter / NppExport).

That is a hash check, not a signature. It proves “what I downloaded matches what the list says”; it does not prove “what the list says is what the author published”. If the list is tampered with (mirror replacement, upstream compromise - and this project has had a compromised update server before), the hash check is bypassed together with it.

What is not validated at all

Plugins placed directly on disk are not checked at all. It is enough to create:

plugins<name><name>.dll

and Notepad++ will load it at startup via LoadLibraryEx (PluginsManager.cpp:131). In the portable build this directory is writable by the current user - no admin rights needed. The installed build only raises the bar to “needs admin”.

So the practical trust model here is: anything that can write to the plugin directory gets code execution inside Notepad++. That is a design decision, not a bug - but it means “plugin” and “malware” are indistinguishable at load time.

Why I am writing this

Not to ask for a plugin review process - that is not feasible, and I agree with that. But “hash-only” is a weaker property than the name suggests, and there is no way for a user to tell “this plugin came from its author” from “this plugin came from whoever could write the list or the folder”.

If the goal is verifiable origin, the direction that actually gets there is a signature (or at least an author public key), not a hash. Even a “first use, shown once” fingerprint would be better than nothing: “this plugin was first seen unsigned, do you want to trust it?”.

Disclosure

This is a limited public note, not a CVE request. I have no exploit to hand out; the point is the trust model itself. If the maintainer considers it by design, that is a valid position - but “by design” is not the same as “safe”, and users deserve to know which one it is.

[PeterJones]

@Firefly0619sec ,

Forcing Plugin authors to sign the DLLs would destroy the plugin ecosystem, as code signing is expensive (compared to the “free” that currently required) – even the Notepad++ developer himself has difficulty getting code-signing keys for the application distribution. It’s way too much to expect a plugin developer to get.

On the other hand, the Plugin List DLL is signed, and the list of plugin hashes is compiled into that DLL, so the hash value is guaranteed to be the one included in the nppPluginList repository at the time that the nppPluginList.dll was built. So if an attacker replaced the remote plugin zipfile download, it would cease to match the nppPluginList, and would be caught. And if someone changed both the zipfile and submitted an update to the nppPluginList repository, there would be a documented change as part of the audit trail, and it would be obvious whether it were the account that owns the plugin or some other user. That seems reasonable enough assurance to me.

So the practical trust model here is: anything that can write to the plugin directory gets code execution inside Notepad++.

Erase the words “inside Notepad++”, and then you have the actual Windows trust model. If you have permission to write to c:\program files\ hierarchy (which is where both notepad++.exe and all its plugin DLLs reside in a normal secure installation), you can overwrite any DLL or any executable inside that hierarchy. Since you could literally replace notepad++.exe with the same permissions to replace a Notepad++ plugin, there is nothing Notepad++ can do to prevent it. Once an infiltrator has gained access to c:\program files\, there is no such thing as trust on the computer, and that is not something Notepad++ can fix.

This is the best design the developer has been able to come up with to allow the application to be extended by plugin. Optional public key-based signing might be reasonable, but it’s never going to reach 100% of plugins (even 100% of plugins in the Plugins Admin list) because not all plugins are actively maintained, and for those that are, not all have developers who are interested in setting up a public key.