Thursday, December 8. 2011On distributing binaries
Many software developers don't care about security. A typical
Java developer downloads the Eclipse binary from eclipse.org, a
website that doesn't even support https. He then continues to
install binary eclipse plugins from several different web
sites. Once development starts, maven continues to pull in
hundreds of plugins and dependencies without checking their
origin.
How do you still want to trust this machine with your private passwords or gpg key? I don't. Therefor I do java development at least in a chroot'ed environment. To make this point a bit less theoretic I've collected examples of compromised downloads or servers in recent months.
sudo make install on any downloaded source code:
The
bumblebee rm -rf /usr disaster. Not so funny: 154 people killed in malware caused airplane crash. or Malware compromises USAF Predator drones
What's the morale? If you're a developer, then please get a gpg key, get it signed by many other developers and sign your release artifacts! And no, just publishing a SHA-1 or (god beware) MD5 hash of the artifact does not provide any security. It may just fool people to believe they'd be secure. (Google Code team, please fix this! Apache people, signing artifacts with gpg keys that don't have any signatures is at best useless!) This blog post has been triggered by a post relating to the issue of binary incompatibilities between Scala versions. If I understand Josh Suereth correctly, he recommends to not worry about binary incompatibilities but to distribute libraries as source code and recompile them when necessary. AMEN! Please, make this a habbit in Scala land! If you then distribute source code in Git repositories you can make use of gpg signed tags. And while you're at it, why not help your favorite linux distribution to package Scala stuff? update: add Horde, Sourceforge, Bit9 case update: gitian is a tool by the bitcoin project to manage a process in which multiple independent parties build and sign binary packages Comments
Will it protect me from backdoors hidden in a library if I automatically compile it from source? Or am I supposed to read and understand every line of code of every library my project uses? Even if the dependency was introduced by another team member months ago?
I don't see how distributing only the source will make us even one bit more secure.
Two mechanisms can help you, if you use software that is available from as source code and cryptographically signed with keys linked to the web-of-trust:
a) You can trace back the person who made (every line of) the code. So it becomes more dangerous for somebody to introduce malicious code. b) If you use build a distribution (like Debian) that is used by many, in universities, government, military, industry, health care, ... then it becomes do-able again that many eyes review the source code.
I would love to be able to sign my git repositories, but how can I sign each commit, or update a master signature upon each commit?
@Andrew: Commit signing is requested by many and on the roadmap of the Git developers.
But you can sign tags since long and it would be fantastic, if people would add a signed tag at least for each released version.
So true. I wrote a similar post a while ago: http://branchandbound.net/blog/security/2012/03/crossbuild-injection-how-safe-is-your-build/
Developers really need to get bitten by this issue before anything changes, I fear. |
This story has been submitted to fsdaily.com! If you think this story should be read by the free software community, come vote it up and discuss it here: http://www.fsdaily.com/HighEnd/On_distributing_binaries
Tracked: Dec 10, 13:50
Tracked: Jan 26, 02:50