Feature Request: Security Measures to Mitigate Malicious Code Injection via Plug-Ins

[Elwoods]

Recently there was a widely publicized attack by injecting malicious code into a library "XZ", which is used in many Linux installations (CVE-2024-3094).
By inserting a Trojan horse in this way, the complete security of the system can be undermined.

In my opinion, the security of KeePass faces a similar threat through the use of plugins. Although the plugins are a real enrichment that I would not want to miss, the risks they pose must be viewed critically.

I would therefore like to suggest some measures to reduce the risk. There will never be 100% risk avoidance, but even small steps can help to make a potential attack more difficult.

My suggestions would be specific:

1. Loading of PLGX plug-ins should be preferred to DLL versions by default. DLL versions should only be loaded after user confirmation. There should also be a warning message if binaries are found (e.g. DLLs) in the unpacked sources of a PLGX. Reason: DLLs/binaries are closed source and cannot be audited.
2. There should be an option in the standard KeePass with which the loaded PLGX plugins are unpacked so that they can be subjected to a source code check by anyone. Similar to the solution here: KeePassPluginsSourceCode. Justification: Audits must be simplified. In particular, a check as to whether what is delivered as PLGX also corresponds to the source code on Github / Sourceforge etc. has to be easy.
3. The plugins should be available for download from a centrally managed repository in addition to their original source. Justification: To prevent code infiltration in decentral hosted plug-ins (e.g. through hacks on self-hosted unsecure web servers).
4. In the long term (but of course very difficult to implement), consideration should be given to an audit system in which, for example, audits are carried out for each plug-in by a voluntary pool of auditors upon initial publication on the central repository and sporadically thereafter. With the audits a "confidence level" could be certified (e.g. based on the number of audits by different auditors, non-existence of binaries, verified widely used binaries, auditability through good documentation, code complexity, etc.) and published on the central repository. Auditors should be selected at random for each audit, i.e. no voluntary reports for a specific audit - this would make the audits themselves vulnerable.

What do you think of the suggestions?

[Paul]

1. DLL is preferred over PLGX. https://keepass.info/help/v2/plugins.html#sec
2. Source code examination is not something anyone can do. If you want to do so, use the PLGX unpacker.
3. Can't be done as plug-ins are by 3rd party authors and we are not always notified of their existence. Even if we were, the overhead is onerous for the single KeePass developer and limiting for plug-in authors.
4. If you can arrange the auditors we should be able to manage that, given the restriction mentioned in 3 above.

cheers, Paul