Verifying that open source software hasn't been tampered with

Question

I'm about to download some OSS software, and I would like to ensure (with a reasonable degree of certainty) that it hasn't been tampered with to insert malware. Specifically, it's a password manager (KeePassX), which seems like an extremely juicy target for hacking, so I'm feeling particularly paranoid.

The two vectors for malware insertion that I can think of are:

• Malware making its way into the official source code.
• A malicious fork or build being substituted for the official one on the website.

The download page does provide checksums; however, this wouldn't seem to protect against the above two hacks.

I don't have the expertise or time to do a source code audit.

What are best practices for checking open source software of a sensitive nature for malware?

Answer 1

If you fear the source, which is what your question implies, there is no way you will trust the software.

The solution is to stop fearing the source.

To do this you can focus on the fact that out of the thousands, probably millions, of OSS software projects, the number of projects that have been infected and that infected code approved and merged into the main codebase is nil.

You can also focus on the logic of the issue: Due to the large number of eyes going over each piece of the code, and the extremely low odds that a sufficient number of those eyes are bought off by the malware makers to force the nefarious code to be included, the likelihood that bad code has made it into a tool such as that is also nil.

For these reasons I try to stick to reputable, well recommended, well supported, and actively developed OSS tools for critical software. In all these situations we're playing with odds. And while the default odds are extremely low, the odds of an active software project being infected are even lower than the default.

Answer 2

How paranoid do you want to be? Do you trust your compiler? There is an interesting story (read the section Reflections on Trusting Trust), from Ken Thompson, one of the original creators of Unix. It describes a system where the login program has a backdoor allowing him to access any machine. The compiler is modified, so that when someone compiles the clean source of the login program, the compiler notices and inserts the backdoor code.

The compiler also notices if someone is compiling the clean source of the compiler, and inserts the proper code there as well. In those days, everything was available as source, but you would need a binary version of the compiler as a place to start. So the malicious code never shows up in the source code, but propagates itself as bits of the system are recompiled. This would be incredibly difficult to figure out, basically requiring auditing the running code.

Back to the original question, you have to trust someone. The question is how far up the chain do you need to go? With a well known project, odds are someone will notice if there is a problem pretty quickly.

Answer 3

If you find a mirror of the packages, you can compare with their checksums.

This would protect against the second vector, provided that the packages were mirrored before they were substituted.

For protecting against the first vector you'll likely have to look at the changes in the source code.

Answer 4

Malware making its way into the official source code.

Unless you are dealing with daily builds this unlikely to happen.

A malicious fork or build being substituted for the official one on the website.

This would require access to the website, which is unlikely to happen without being noticed by somebody, you should be far more worried about MySQL's website being compromised.

The download page does provide checksums; however, this wouldn't seem to protect against the above two hacks.

Sure it does... Somebody had to post those values they were not generated automatically.