Slashdot Mirror
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...
I hate to say it, but do the Debian developers use their own product? Were they not kept up to date? Or are all Debian boxes vulnerable? I noticed that nowhere did they mention just *how* they were compromised. Sure, it might be embarassing, but when a major distro's servers get cracked it doesn't help confidence in their distro. Letting us know what service is broken (and hopefully how to fix it) would go a long way towards correcting that.
But how do you know.? They could say "we didn't go gold because we wanted to get the bevelled edges on the windows just right" or crap like that.
MS, unlike Debian, aren't very open about it when they are compromised (remember when the russians were on the MS corporate network for MONTHS? No? That's because MS controls the mainstream press, and played it down. But crackers had access to the Win2k sources for several weeks.)
This is horrendosuly bad security practice - even if you are using closed source stuff and think open source stuff is a load of politically-loaded garbage, you as a sys admin STILL NEED TO KNOW if your upstream source for that closed source stuff is compromised. Disclosure of compromised security to customers is VITAL for the security OF THE CUSTOMERS.
MS worry far more about their reputation for security (not that there's much left...) than security, and it's only because lots of customers are too uneducated to grasp the above that they still get away with it.
I've seen no confirmation of this by anyone @debian.org. So what's the deal? Real or not?
There was some fuss on the debian-user list, and this was labeled a hoax, yet I saw no official word that it was true.
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.
OpenBSD prevents stolen passwords from being used to log into a system? How?
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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
Then the next point of failure becomes the keyservers. How do you know you imported a good key, and that the keyserver hadn't been compromised when you did it?
This probably would be no good as a way to sneak backdoors onto more than a few machines, since keys are usually stored once and used often. But it would be good to have some sort of key distribution and verification system. Imagine a key publisher having 7 peers, and where they carry same keys, requiring 5 to 7 matching signatures, and point a nasty finger at the odd one(s). More than two mismatching signatures and the system quits publishing keys.
Of course then the key publishers themselves then become a choke point for a DOS attack, of sorts. Make updates grind to a halt as a new exploit is emerging, widening the window to utilize it. But still, most keys are stored, and the voting fails only stop distribution and verification.
Thorny issues, part of why PKI is considered 'hard'. But at least my suggestion is reasonably decentralized (I didn't say how to get a new key into the system) and has publishers voting on the intersection of their published keys, not requiring every server to publish every key.
The living have better things to do than to continue hating the dead.
I wonder if someone really believes that Debian make the stable releases for stability and security rather than incapacity of releasing and supporting an up to date system.
I hate that excuse! Oh well to make it stable we release slowly. No, you release slowly because you don't have enough devs to get it done at a reasonable time.
Even the so-called "unstable" distro that you are supposed to run to get "up to date" software is always 3 months to a year behind depending on the package.
If FreeBSD can stay up to date and be stable then its obvious debian is offering its users an excuse made of false choices...Be up to date and unstable or unstable and old. That's their group think mantra. They don't even realize no one but a true believer buys it. Sure a distro has to be sort of old to be stable...BUT NOT THAT FREAKIN' OLD.
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
If these projects are open and both admit to what happened and describe how their systems were compromised, then other people can learn from their mistakes.
It's one of the things which contributes to the secure nature of the software - if it turns out that, say, version 1.337 of the Foobar daemon was compromised, I bet a lot of sysadmins will be double-checking to make sure that they're not running that particular vulnerable version.
I'd rather there was honesty that people can learn from than the permanent claim that it's the best software ever and can never go wrong - by acknowledging errors and mistakes, things can be made better.
Actually there is a method for securing against lost passwords (by this I mean intercepted as in looked over shoulder, recorded key clicks, etc.) and that is the one-time password method combined with some other secondary authentication method. It is, however, extremely difficult to implement successfully. I have been kicking around a method creating my own system for this for my servers. I suspect that I wont be bright enough to do a good implementation of it though.
Of course this has nothing to do with the earlier post being both right and wrong. (right in the sense that Joe CTOs are dumber than a bag of doorknobs, and wrong in that it is not a technical reflection of relative security between MS and Linux).
Why? Microsoft has been compromised hundreds of times and, according to them, it hasn't hurt their credibility a bit!
Look, this is nonsense! There is no such thing as a perfectly secure system.
Or, to put it another way: The price of freedom is eternal vigilance.
When are they going to force everyone to sign the package with GPG and have a warning like ssh when a key has changed when you dist-upgrade?
It's about time will all the server compromised these days...
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.
Unfortunately, I believe that that's already the case, and has been for as long as I've been a Debian developer. I believe what really happened is that somebody's home account or something was compromised, and they did the stupid passwordless ssh key thing (instructions for which are even on the Debian devel web site!). Even if they didn't use passwordless keys, rootkits with tty-loggers make it pretty easy to sniff a key's password if it's typed over the network.
noah
You know, an enterprising attacker could just pull the trust network down. Someone with sufficient skill could very easily just work on Debian for five or six months, get trusted, and embed a subtle bug into a remote point.
I mean, we can't find the unintentional ones. What makes you think we could find one chosen for its obscurity?
StoneCypher is Full of BS