Slashdot Mirror
Debian Server Compromised
Security News writes "According to a post on the debian-devel-announce mailing list "Early this morning we discovered that someone had managed to compromise gluck.debian.org. We've taken the machine offline and are preparing to reinstall it. " gluck is a core development machine."
No, we didn't. The server holding the Debian archive did not succumb to the exploit, because it didn't run on an x86 machine and the people exploiting it only attempted to run x86 code. Furthermore, data on the servers that *did* succumb to the exploit got checked before it became available again.
http://www.debian.org/security/
Security (not feature) patches are backported if possible, and if the patches are too extensive, an upgraded version goes into Stable.
"I don't know, therefore Aliens" Wafflebox1
You do understand that everything downloaded from update.microsoft.com needs to be digitally signed, right? In order to actually subvert the downloads, an attacker would not only need to take over the system, but would also need to sign the modified download with a Microsoft key. That's hard: the private keys for signing code are kept on a machine inside a SKIF. Last time I checked, code was taken to be signed by sneakernet, so that there would be a physical airgap between the network and the signing system.
Changelogs don't provide any form of security, and package changelogs have been standard in Debian since many, many years ago. (Long before Ubuntu was a gleam in Mark Shuttleworth's eye.) Changelogs should only be treated as a convenience to the user.
And apt supports GPG signing of the Release file, which contains an MD5 and SHA-1 hash of the Packages file, which contains MD5 hashes of the packages. (In other words, apt already does package integrity checking.)
To get something done, a committee should consist of no more than three persons, two of them absent.
It might be nice to include signed authentication of at least the changelog, if not the package itself, to ensure authenticity of upgrades.
Debian has been checking digital signatures on every package installed for almost a year now. See here.
Of course, I run testing, so I have no idea when this got into stable.
Not public information yet. If you're subscribed to debian-devel-announce, you'll be the first to know.
The announcement says:
We're still investigating exactly what happened and the extent of the damage.
We'll post more info as soon as we reasonably can.
If the ones affected can't say, who can then.
(yeah, yeah... "the ones who attacked the server").
You do understand that everything downloaded from update.microsoft.com needs to be digitally signed, right?
Btw, Debian also does digital signatures for every package installed (see here). I don't think they have gone as far as having an air-gap, but it does mean that a regular hacking won't be able to silently corrupt packages.
Debian's system is actually quite cool, since it can check *every* program installed, and not just core OS updates (courtesy of apt controlling 99% of software installation). In fact, you can add additional keys for other package sources (I run some unofficial packages, but those developers also sign their packages with their own keys, so it is covered as well).
...Anybody who didn't understand the real meaning of "compromise" needs to re-read the article, substituting "compromised" with "rooted." The attackers didn't kill the server or knock out a service. They rooted the box, and the Debian devs are trying to cover themselves somewhat by ambiguating the exact nature of the attack.
~ C.
but with a compromised dev machine, one could patch in back door code that gets signed as valid.
pr0n - keeping monitor glass spotless since 1981.
To get something done, a committee should consist of no more than three persons, two of them absent.
Note that the security features will only be noticeable when a check fails. If all the checks pass, then you'll never notice the features at all (unless you notice that it downloads the Release.gpg files, if Ubuntu shows what files it downloads).
To get something done, a committee should consist of no more than three persons, two of them absent.
Yes. But it really really sucks. A lot. If you're a major control freak (or just like avoiding auto-updates and such) you could probably go that route. Useful for people on dialup ... download important updates, maybe dump them to a jumpdrive or burn a cd when you've got a couple of them.
I think they also do monthly iso-images that are just compilations of all the update installers in a given month, for the same reason -- not everyone's got a good net connection at home.
I've got a lot of other problems with debian which prevent me from using it. However, their security track record is not really one of them. Given the huge project with a very large number of machines and developers, and their long track record with very few incidents, I don't think it's fair to pick too much on this one.
That, and Gentoo is hardly immune to this sort of thing either.
DSA = Debian Systems Administration (team)
/* FUCK - The F-word is here so that you can grep for it */
Well, considering that DAT stands for Digital Audio Tape, I find that a bit unlikely...
How old are you? Gotta be under 25, easy.
4mm helical scan DAT tapes were very, very popular for enterprise data backup. Do a quick google on "dat tape backup" and enlighten yourself.
-Charles
Learning HOW to think is more important than learning WHAT to think.
You can import the appropriate keys using PGP. If I recall correctly a google search for the error messages apt is emitting will find you some discussions on this matter, including fixes.
Oh boy... Low UIDs hardly instill authority!
;-)
Take it from someone with a waaaaaaayyyyy lower UID as yours!
But to your original point - I'm not too sure you can rule out future break-ins at all. It would only be REALLY stupid, if both breakins happened through the same setup fault.
But I don't think debian has a full time security admin who constantly and ACTIVELY monitors every debian.org box, like other big name companies might be able to afford to.
Secondly, the sheer multitude of packages, and frequent updates/upgrades of packages will make it fairly impossible to keep a machine 100% break-in proof.
Of course, I don't like break-ins - especially on servers of a distribution I'm actively using; but I think it's wrong to panic about it either.
More importantly - while I see the need to reinstall quickly, has anyone there found out HOW the break-in occured? Has the hole been located? (...and is it known how to fix this particular one, before the same guy just uses the same "back door" again?)
That's why, as a l337 hax0r, you can run a mixed system. Nobody stops you from installing unstable packages, right from apt, even! (Check out that -t flag!) Or even better, you can actually build your own source.
The argument for Gentoo that "I like the idea of building my own source" in the sense of "I like getting down and dirty into my system" is really kind of bull. I ran Gentoo for a while, and I thought they had done some amazing work. Portage/emerge is just amazingly well done, and it's nice to have code that's been optimized for my hardware requirements. It's not exactly scalable (maintaining a large set of diverse hardware is a lot harder), and it can lead to untenable situations and instability, but it's still damn cool. And you know what's really cool about it? It's the convenience of apt, for source packages! Please disabuse yourself of the notion that you are "building your own source" -- the Gentoo maintainers are very diligently, very cleverly packaging the source so that you can specify a set of system parameters and then let it build. If you really want to get nitty gritty, run Slackware (although, I guess they have package management now, too). Gentoo has lots of merits, but the truth is, most Gentoo users know no more or less about how things work than an average Liinux user.
For me, in the end, the speedup I was getting just wasn't making up for the hours it would take each time I ran a system-wide upgrade and the unexpected conflicts because the USE flags that made each package special for MY computer were screwing up MY computer something fierce.
So are Debian packages. Check "man apt-key" about that.
Life is just nature's way of keeping meat fresh.
http://www.debian.org/News/2003/20031121
The vulnerability they were hit by was a previously unknown vulnerability in the kernel.
The previous attack was one that can be applied against any platform: somebody used their password over an unencrypted channel (presumably a non-Debian channel, since all the project ones should be encrypted), and somebody else sniffed it and used it to gain access. You can't really do anything about that.
The mistake debian made was they allowed plain-text passwords. In this day and age thats pretty silly. They should have disabled all authentication methods but the RSA or DSA key exchanges of ssh. Even if some junior developer had a losing password (or one they resused / revealed) the attacker couldn't get in without also getting a copy of that developer's private key file. Guessing the standard 1k RSA key be brute force would take 10^308 tries. That should put it out of the range of simple guessing.
apt-get archives are now signed too. In Etch (testing) and Sid (unstable) apt will check the integrity of the packages for you, but the entire archive is signed. Just look at woody or sarge,
http://http.us.debian.org/debian/dists/woody/
http://http.us.debian.org/debian/dists/sarge/
Then locate the file Release.gpg. That is the signature for the release file.
For anyone still following this story all these hours later, there's a new post on debian-news with a bit more detail about what happened here.
The short version is, it was a privilege-escalation exploit triggered from a compromised user account, the server in question is now restored, but several others are locked down pending inspection. Also, it says the regular and security archives were not in danger. The exploit was a known issue in the 2.6.16.18 kernel running on gluck at the time of the exploit.
Interestingly, the window between the compromise and the lockdown was less than two hours.
2*3*3*3*3*11*251
In related stories: Microsoft Windows Servers remain secure.
The most dangerous strategy is to jump a chasm in two leaps. - Benjamin Disraeli