Slashdot Mirror
More Info on Debian.org Security Breach
mbanck writes "James Troup (part of the Debian System administration team) has published more information on the recent compromise of four debian.org machines. The attack vector seemed to be a sniffed password of an unprivileged account, from which the attacker somehow managed to gain root and install the suckit rootkit and crack the other machines. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen.Note that the main ftp archive running on a sparc machine was not compromised, so the exploit might not yet be ported to non-i386 architectures."
This was both user and admin stupidity I guess. Admins who care about security shouldn't permit access through cleartext passwords and users shouldn't send their password in cleartext if they care about their account. Unfortunately many users don't know about this risk.
Probably the closest you'll get to a "good" system would be something like S/Key or Opie (debian packages: opie-server, opie-client, libpam-opie - Use OTP's for PAM authentication) for generating and using a one-time-pad of password systems. The issue in this is that you must generate the pad in some secure fashion, if someone sniffs your pad because you downloaded it over the network, you've lost.
You could easily keep a pre-generated giant pad itself on a usb drive or something similar.
If I have been able to see further than others, it is because I bought a pair of binoculars.
The root of the problem is with the root account.
SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done.
I would think that it's time for the big players like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines.
It's being incorporated into the stock kernel for a reason. Use it!
Why not run something like LIDS. You can lock access to your logfiles so that only certain processes can run them.
It looks like a bit of work to set up and administer but you'd think that an organization like Debian would make sure all their computers would be running it.
War is necrophilia.
Debian = Debra + Ian Murdock
~
~
:wq
Not only isn't Akamai just a proxy/cache server, they just hold signed files. If someone managed to hijack/compromise those, the downloaded updates would not verify on the user's machine, so it's pretty much a void argument.
that's the whole point of LIDS.. LIDS provides kernel hooks to add extra level of access restrictions to the root UID. read up on LIDS before you speak.
I have dealt with this rootkit for nearly 4 months when it first appeared. The fairly safe methods for avoiding this is by 3 steps which I have used and it works well since then.
/tmp to it own partition and set it as noexec, nosuid and give it plenty of space, around 200 to 500 megs for it.
Move the
Patch the kernel with either Grsecurity or Openwall Patch on 2.4.22 kernel and set it as mononthlic kernel, not modular with no open hooks for adding additional modules.
Then I installed the suphp module for PHP to run scripts as users instead of nobody, especially when people trying to exploit it. I get it at www.suphp.org and it works extremely well. Since the changes, I haven't seen any rootkits being successfully implemented on the servers I admin. And note the fact that I manages over 260 servers for various clients points to the track records.
-- Amazing how the Internet still humms along.... -- Dispite all the flaws of Micro$oft in their software!
It was bitkeepers cvs, not kernel.org which was compromised.
Here are two useful utilities to flush out the SucKIT rootkit:
Kernel Security Therapy Anti-Trolls
and
Kernel Security Checker
Have a nice day !
Muchas Gracias, Señor Edward Snowden !
That's what he meant by his comment - the Debian Project is effectively halted by this - and obviously that can't go on for long.
[1] You can obtain a listing of these by running the command ldapsearch -h db.debian.org -x -b dc=debian,dc=org '(objectClass=debiandeveloper)' from a internet-connected host.
It is sad to see one weak password responsible for such a breach.
:(
//hdw
Eh? Why is everyone talking about a weak password?
The article says sniffed password.
I assume that they're not using cleartext password authentication which means that it wasn't sniffed on the wire, it's was sniffed on a (compromised) box the some user used to log in.
And if the clientbox is compromised it doesn't matter if you use password or a passphrased key.
Even keeping your key on something removable (like an USB keychain) doesn't help you, the cracker can easily snarf both key and passphrase
The only way to bypass that would be an external pinpad style device.
Executive Pope (small) Kallisti Engineering
The primary Debian machines are in colo facilities
in the US and Netherlands (there are buildd machines available to debian developers in various locations). The machines are beefy enough - HP
recently donated a server with 48 GB RAM, for example. I believe the bandwidth out of ftp.debian.org is Gigabit ethernet (and having only that to the mirrors will be a bottleneck
when sarge is released!)
So, no, they're not in some dudes basement; we have good facilities courtesy of our sponsors.
- Alastair
Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist
Hmm... maybe SELinux would have stopped this? Doesn't it prevent hooking into system routines? If so, then it's a great excuse to see better SELinux support in debian :)
Palm scanning only proves you have the hand of someone allowed to access a system. Retina scanning only proves you have the eyeball of someone allowed to access a system.
Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse. So you can't fool these scanners just by cutting off someone's hand or ripping out their eyeball. (Although it might be possible to manufacture fake contact lenses or glue-on fingerprints that would work.)
On the other hand, the basic weakness is that the biometric signature is still just a big password. You can "sniff" the signature by installing a fake reader. You can steal the signature off the harddrive of the domain controller. You can bypass the reader by splicing the wire. And your "password" is the same for every site.
Bottom line: I would sooner trust a token card.
-a
The 'almost' is explained later on in the article. The one missing update was a postgres fix which could
never have been used to gain root privileges
One if the reasons we are taking so long with all this is that we simply do not know how exactly root was gained. When we do do and we have a fix we will gladly reveal that along with a security advisory detailing how you can protect your systems as well.
2.6 does indeed have the LSM integrated in - that's step of abstraction up from the original SELinux. It is essentially a set of appropriate hooks into the kernel for running SELinux style security. There are actually other packages (LIDS for instance) that use this system.
The end result is: We will soon have a very strong security model built in to the standard stable kernel. The sad thing is that it will be off by default, and you will still need the set of userland tools that use it.
We have an excellent opportunity (with the 2.6 release) to seriously increase the security of Linux systems. People need to start promoting LSM modules and programs NOW so that we can get this to be the default state of most installed Linux boxes.
Jedidiah
Craft Beer Programming T-shirts
One would hope so, but the evidence isn't as promising.
Search 2010 Gen Con events