Debian Project Servers Compromised
Sean was one of many to pass along
the bad news
from the debian-announce mailing list: "Some Debian Project machines have been compromised. This is a very unfortunate incident to report about. Some Debian servers were found to have been compromised in the last 24 hours. The archive is not affected by this compromise! In particular the following machines have been affected: 'master' (Bug Tracking System), 'murphy' (mailing lists), 'gluck' (web, cvs), 'klecker' (security, non-us, web search, www-master). Some of these services are currently not available as the machines undergo close inspection. Some services have been moved to other machines (www.debian.org for example). The security archive will be verified from trusted sources before it
will become available again." They were going to announce 3.0r2 this morning; they've checked it and it's unaffected but obviously they're still postponing that release.
Of course this raises the whole issue of apt-get. We all rely on apt-get update && apt-get upgrade, all it takes is someone to compromise the servers and insert a backdoor
This is the second time this has happened to a big open-source project (the first being the GNU servers a while ago). All packages by both groups are "md5" signed, which is supposed to protect against malicous hacking. However if the root server is comprimised, this doesn't help. Companies (including at least Microsoft, and the people who make ad-aware) who distribute files over the internet sign them with an RSA (or similar) key, and the computer which does this signing is kept disconnected from the internet. For such large projects which are installed by millions of people, might a similar system not be a good idea?
Combination - fun iPhone puzzling
Are deb's signed? (I'm not that familiar with debian but I'd imagine they are) If so then just tell apt-get to not install debs that don't match a known signature...
The server that pushes .debs to archive is running debian/sparc (donated by sun btw), so probably the cracker didn't know how to port his leet exploit to sparc (all the comprimised machines were 1386).
signatures pending - ansa@kos.to - (dont mail there)
At this point I would like to see the debian team develop some written policies and procedures for how they intend to prevent this sort of thing in the future. I checked the site and while there's security info for how to secure your box, there's no policies on 'how does the debian project secure itself'.
Lastly, one concept you have to keep in mind, we have no idea how often other OS's key servers are cracked because they'd never tell us.
First GNU, then Bitkeeper, now this, whatever shall we do?
Simple, the technology has existed for decades now.
A little something I like to call "Public Key Cryptography"
With this "Public Key Cryptography" you could conceivably sign software in such a way that it could not be altered without breaking the signature, AND ensure that nobody else could forge this digital signature (you are keeping your private key private right?)
MD5 Hashes are a step in the right direction, but by themselves are meaningless. Sort of like improving your home's security by drilling holes in your door to mount a deadbolt but not actually taking the final step and INSTALLING THE DEADBOLT.
So let's take these MD5 hashes and encrypt them with the package maintainer's private key (or distribution maintainer, whatever). Then dpkg (or rpm, emerge, whatever your favorite package tool is) could be written to decrypt this hash with the corresponding public key. Wait, there is more! Then it could generate it's own MD5 hash of the package in question and COMPARE it to the decrypted hash it just created. If they match, the package is unaltered AND came from a trusted source. This my friends is what we like to call a "digital signature"
I don't care how you do it, GPG, x.509, whatever. I'm actually leaning toward x.509 since it seems to me to make more sense to have the distro maintainer run his/her own CA and issue certs to package maintainers. This CA could then be included in whatever package tool is used and viola. No mucking about with the web 'o trust (Which rocks for ad hoc trust relationships like between people emailing each other, but sucks for this kind of hierarchal stuff)
So what do you think everyone? Good idea or should we wait for a few more server compromises before we think about securing software repositories?
Finkployd
This news made me realize how much I depend on Debian. At the moment, every one of my machines (four servers, three workstations, and a laptop) runs Debian. I've been running it as my primary OS for... two years? So far I haven't paid a dime for it. It is a nice advantage of Free Software to be able to use it for free, but given the fact that I'm way out of "try-before-you-buy" mode, I'm going to send them a check today. Software in the Public Interest was founded by and is the current funding source for Debian.
One server compromise in the two years that I've been watching by a company with zero product sales revenue is pretty impressive. An OS that is (IMO) dramatically superior to any commercial offering for free? They've earned my respect, and have clearly earned my cash.
Stop-Prism.org: Opt Out of Surveillance
Thanks for confirming this. Unfortunately, the way you confirmed it is very dangerous.
Your message contains:
So from now one, your "confirmation" can be used by anybody who wants to claim that some random report of theirs is "confirmed by a debian developer". Until you revoke your own key, of course. That's a pity.
-Raphaël
Steve from Debian Security Audit project says this occurred due to a password goofup so this doesn't necessarily apply here but it easily could have:
Machine as important as these should be running some sort of Mandatory Access Control system like SE Linux. I have done an evaluation of all of the root exploits I could find over the last few years and SE Linux would have prevented every one of them because the MAC system prevents unauthorized priviledge escalations. You can test drive my SE Linux box by telnetting (not ssh) to selinux.copilotconsulting.com with user root and password root.