Slashdot Log In
Kernel Exploit Cause Of Debian Compromise
Posted by
simoniker
on Mon Dec 01, 2003 04:40 PM
from the slightly-disturbing dept.
from the slightly-disturbing dept.
mbanck writes "The cause of the recent Debian Project server compromise has been published by the Debian security team: 'Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space'. This issue has been fixed in 2.4.23. Thus, the Linux kernel compromise was not Debian specific."
This discussion has been archived.
No new comments can be posted.
Kernel Exploit Cause Of Debian Compromise
|
Log In/Create an Account
| Top
| 673 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
A shift of focus (Score:5, Interesting)
(http://00f.net/)
Re:A shift of focus (Score:5, Funny)
It's fun to see how security research shifted from applications to kernels lately.
Fun!? You must be Klingon.
Re:A shift of focus (Score:5, Funny)
Today is a good day to get rooted.
Re:A shift of focus (Score:5, Informative)
Traditional local root exploits are all based on overflowing a setuid application or server. But if the box doesn't have any vulnerable apps installed, the attacker is SOL. However, if the kernel itself is exploitable, it no longer matters whether those setuid programs are present. All you need is to somehow acquire local access, and wham, you are root.
To summarize, kernel exploits are very convenient for turning local user account compromises into full-blown root compromises.
Re:A shift of focus (Score:5, Funny)
(http://frymaster.ca/ | Last Journal: Monday September 15 2003, @12:58AM)
does this code belong to sco?
Re:A shift of focus (Score:5, Interesting)
(Last Journal: Friday February 21 2003, @08:57PM)
We should point out that you're talking about common kernels like Linux today, not that this must apply to any OS kernel. For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries. The cracker's problem then becomes how to get an existing userland program (compiled by the trusted administrator) to issue the kernel call that results in the exploit, which is a much harder problem. A program may not ever make that system call, or may check its input so that you can't make it do the system call with (presumably) invalid parameters. In most cases, I expect that this means you have to insert a backdoor into a common program and wait for the trusted administrator to compile it for you.
This sort of security is probably overkill and too tedious for a desktop box, but not unreasonable for a server which should only have a few programs installed and running anyway.
Re:A shift of focus (Score:5, Funny)
(http://www.biglumber.com/ | Last Journal: Tuesday November 27, @12:44PM)
Re:A shift of focus (Score:5, Informative)
(http://bangpath.org/)
Re:A shift of focus (Score:5, Informative)
(http://bangpath.org/)
This thread [debian.org] on the Debian mailing lists talks about this issue, and a poster in this thread notes that SE Linux is capable of closing this hole (with example). I don't recall offhand what tools are available in grsecurity (www.grsecurity.net) to address this issue; check out the grsec mailing lists for more info.
Re:A shift of focus (Score:4, Insightful)
A desktop system is exposed to tons of potentially hostile data. Strings are like acid, and a complex language like HTML is just asking for trouble.
Don't get me wrong, OpenBSD is waaay into diminishing returns territory as far as security goes, but there's a few things that could be done to get 90% of the benefits, eg propolice in the kernel and W^X.
Re:A shift of focus (Score:4, Interesting)
(http://n0x.org/ | Last Journal: Sunday April 30 2006, @11:12AM)
It's also possible to use SELinux [nsa.gov]. With this module you can in details give permissions to any object in the system. A web server would not be able for example to run
Kicking it up a notch. (Score:5, Funny)
Pretty good if you know how to spice it right. The trick is, knowing you've got crow to eat. How's that mystery meat you're chewing on?
(there's a joke about feeding trolls to be made in this somewhere)
Shows the dangers of C (Score:4, Funny)
Well then they'd better get some help (Score:5, Funny)
You appear to be trying to write a kernel. Do you want to:
Re:Shows the dangers of C (Score:5, Funny)
(http://stefanco.com/ | Last Journal: Sunday October 14, @11:09AM)
Re:Shows the dangers of C (Score:5, Funny)
If you can't read your own code who else can..
what kind of person... (Score:5, Funny)
(Last Journal: Sunday November 28 2004, @11:03PM)
Re:what kind of person... (Score:4, Informative)
(http://users.rcn.com/smallpond1/ | Last Journal: Wednesday April 30 2003, @11:25PM)
spammers [bbc.co.uk]
People who expect to make money by hacking systems and using them to send millions of unsolicited emails.
Re:what kind of person... (Score:5, Informative)
ashridah
Re:what kind of person... (Score:5, Insightful)
(http://www.adamhooper.com:4242/)
What kind of person spends that much time trying to find exploits in operating system kernels?
The kernel developers, i.e., Andrew Morton. Good for him, too.
There *was* a patch before the Debian systems were compromised. Hopefully in the future these things will be given more attention before they blow up.
Re:Well, well, well... (Score:5, Insightful)
A couple of points...
1) Note that of the 15 listed advisories:
5 are the same BIND DOS vulnerability
2 (or 3 if you count Turbolinux's mega-update) are the same Ethereal vulnerability (DOS, possible arbitrary code)
2 are the same stunnel hijacking vulernability
2) None of these vulnerabilities lead to a remote exploit (although it could be argued one might be able to create a favorable condition with the ethereal issue)
Sure - Linux runs buggy code too. If that's your point, make it. But this hardly seems to be a suitable response to the parent's (semi-trollish) comment on MS' run of remote exploits.
What Crow? (Score:5, Interesting)
(http://www.pobox.com/~rwhite)
Would that be that a legitamate error was found verified and fixed in public in just about two weeks with no hiding or spin?
If Windows had a memory allocation error (application memory space being the thing controled by brk) of this sort would they allow it to be publicized?
Once they made the "patch" available, would you be able to apply it to every past version of Windows?
Would you be able to verify that the patch was applied to windows?
If Debain's FTP server had been running IIS and windows, what kind of forensic annalysis would have been done, and how LIKELY is it that the *SINGLE* *INCIDENT* compromise would have lead to a complete and detailed report from Microsoft, and a fix?
The "linux is more secure" argument is not (truthfully) based on the idea that linux is inherently error free. It is based on the idea that the persons experiencing the problems can determine what those probems actually are; come up with a fix; have that fix reviewed [and installed] (by all who care) *WITHOUT* needing to waking some sleeping-bear corporations nacient interest in the suffering of their lowly surfs... er... "customers".
Re:Well, well, well... (Score:5, Insightful)
(http://www.mikeash.com/ | Last Journal: Wednesday August 11 2004, @12:57AM)
The worst Windows exploit of the year: a hole in the RPC services (which you can't turn off) that allowed a worm to gain control of millions of Windows boxes, disrupting the entire internet.
How does this make Linux equally bad as Windows, then?
Re:Well, well, well... (Score:4, Insightful)
(http://slashdot.org/)
2) You don't know how many persons used this exploit to take over Linux servers
3) You don't know how many Linux servers were taken over by this exploit
4) Yes, When an exploit hits Windows, it hits many more machines, because there's many more Windows boxes than Linux
5) You obviously have missed all the remote exploits affecting tons of server software on Linux this year(openssh, apache, etc...), any of these could lead to owning the whole machine when used with this local exploit
Re:Well, well, well... (Score:5, Insightful)
First the exploit compromised one of the largest linux distribution and potentially they could have put trojan horses in all our packages and we would really be up shit river when that happens.
Secondly, we are no longer getting package updates so they have successfully stopped Debian development while they patch all this.
Although it's not in the scale of windows, if GNU/Linux had larger marketshare this would have been a big deal.
sri
Oh... (Score:1, Funny)
Userland exploits (Score:5, Funny)
(http://www.swampgas.com/)
Yup (Score:5, Funny)
(http://slashdot.org/ | Last Journal: Thursday August 07 2003, @02:38PM)
Re:Userland exploits (Score:4, Insightful)
Re:Hmm, Methinks I've Heard this theme before (Score:5, Funny)
(http://slashdot.org/)
I'm sorry Dave, I can't do that...
Hurray for the Debian Security Team! (Score:3, Informative)
(http://slashdot.org/ | Last Journal: Sunday September 09, @05:43PM)
Hats off to the Debian Security Team.
Re:Hurray for the Debian Security Team! (Score:4, Insightful)
Re:Hurray for the Debian Security Team! (Score:5, Informative)
(http://troed.se/ | Last Journal: Wednesday April 16 2003, @03:42AM)
Quoting the Bugtraq post:
This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Re:Hurray for the Debian Security Team! (Score:4, Insightful)
(http://www.adrianbaugh.org.uk/ | Last Journal: Wednesday December 17 2003, @07:58PM)
I'm guessing it was found and corrected, as a bug, but not thought to be exploitable, therefore no security announcement[0]. Later on, when debian.org got cracked, someone put two and two together and made the security announcement. I must admit, it seemed fairly weird to me for a long time, and I thought up a few lovely conspiracy theories, but in the end I think the simple oversight scenario is the most likely.
[0] After all, plenty of bugs get fixed in the kernel without being specially announced. If it was subtle someone probably just overlooked the fact that this particular bug was more problematic than any of the others fixed in that patch.
How did they get in to run a userspace util? (Score:2)
That still doesn't get you into the box; you still need to run something in userspace- and thus I think claiming(based solely upon the evidence presented in the /. story) that the compromise was not Debian specific to be premature. Has it been established how access was obtained into the machine in the first place?
Re:How did they get in to run a userspace util? (Score:5, Funny)
(http://www.google.com/)
Or perhaps "she" sniffed a password?
I refuse to believe that the really hot, Debian-using, password-sniffing, root-exploiting geek girl is a myth.
RTFA (Score:5, Informative)
(http://www.cowsgomoo.org/)
Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and 2.6.0-test6 kernel tree. For Debian it has been fixed in version 2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and version 2.4.18-11 of the alpha kernel images.
How does this compare... (Score:2, Insightful)
(Last Journal: Sunday November 21 2004, @01:09AM)
Re:How does this compare... (Score:4, Insightful)
(http://jesus.everdense.com/)
Actually the Windows story was about how Microsoft had not patched an exploit they had known about for months.
This Linux exploit had ALREADY been patched.
Re:How does this compare... (Score:4, Insightful)