Slashdot Mirror
Kernel Exploit Cause Of Debian Compromise
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."
to the winodows hole found the other day. Has anybody heard if that was fixed yet(not sure if it has been 48 hours yet). Technically this hole was fixed before it was found. It looks like another win for open source.
Stay tuned for new sig...
Programming can be fun again. Film at 11.
Linux is a compelling choice in the Free Software world because of its pace of development and wide availability of software. However, it is this strength that is becoming a weakness. Perhaps it is time to slow down and review with more vigor to mimic the accomplishment of OpenBSD.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
No really, a user account is as good as root on almost all systems. If you need security, don't have user accounts on the system.
The management of the incedent seems very professional to me. Thanks to all the people who had a lot of work because of this. They keept the reputation of debian up! Which is a good thing since this is my favorite distribution. :)
Disclaimer i'm no debian devel
Comment removed based on user account deletion
I agree with you totally. It's one thing to say that Linux is rock-solid secure, but in the real world this just might not always be true. It is however, a good thing to be able to say that the parties concerned with this particular security breach have been forthcoming to the community. A large part of security is just that. Hats off to the debian people.
There would then need to be a vulnerability in apache/httpd to allow a user to execute arbitrary code.
it seems everyones favorite whipping boys did alot of work in finding and fixing this bug. AND THEY SHARED THE INFO, who says corporate linux is evil now!@
For The Best Jazz/Hip-hop fusion > COlD DUCK
Oh, I am sure that there are very few people who really sit down and think "Hmm... how could I find an exploit in the kernel?". I think it's much more likely that it's some fairly normal programmer, working on something completely unrelated who one day makes a call the wrong way and finds that it crashes the kernel. And there comes the choice, to be a nice guy and send a mail to LKML, or to check that nobody seems to have noticed it yet and use it to break into some interesting place?
One scary thing to consider about open-source software is that vulnerabilities are published in gory detail often before people bother to upgrade to the patched version.
This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
If this was found after 2.4.22 but before 2.4.23 release then it should have been announced and patched. How is this any different than what Microsoft does? We complain (rightfully so) about security through obscurity and lack of transparency. In this case a KNOWN kernel exploit was left in the open for 1-2 months?
Looking at the 2.4.23 CHANGES file I'm still not clear who/what fixed this. The closest think I see is: ": o Add TASK_SIZE check to do_brk()". Nothing from Andrew Morton's CHANGES entry implies a fix to this. Perhaps "make printk more robust with "null" pointers?" How do we know? Why wasn't it reported to the security groups immediately when it was found (or was it?).
Nobody says it's OK. This is a serious problem. I was just saying that this problem was not Debian-specific, i.e. it could have happened on any other Box running a (by that time) released Linux kernel, as long as the attacker had local access.
what's Debian without the Linux kernel?
Not much. But note that Debian also works on Debian (GNU/)*BSD and Debian GNU/Hurd, not only Debian GNU/Linux.
Michael
You know, people hack things. Kiddies hack servers.
Why does it always have to be a "determined effort" against Open Source? Honestly...how paranoid do you have to be to think that? You do realize a lot of idiot kiddie (and professional) hackers are aware of Linux.
Let me put your underlying implication to rest--no, it wasn't Microsoft. No reason to believe such. It was just some idiot hacker, like it always is.
"Sufferin' succotash."
If fixes are made which affect security, the ChangeLog should clearly spell out that it was a SECURITY fix. I guess people don't want to admit that they have found a security problem...
Part of what you say is right... However, the difference is that with Windows, what you hear about are *remote* holes, while in this case, it's a *local* hole. That makes a big difference. Local holes are frequent on any OS and regardless of what you do, a rogue local user can always do bad things. Remote holes are much worse, as anyone can attack your machine, not only local users. There have been very few remote holes with Linux (at least compared to Windows).
Opus: the Swiss army knife of audio codec
You're right, of course. This is an instance of a real security hole discovered in the kernel itself, and not of the garden-variety "could-theoretically-happen-under-XYZ-circumstance s" type you usually see with Linux.
So that makes...hmmm...one. One real hole in the Linux kernel this year.
Congratulations! You've proven that Linux isn't perfect. Which those of us who aren't trolls or delusional already know.
Remember that unless you have untrusted local users, the patch is not critical.
Opus: the Swiss army knife of audio codec
Good luck!
Use ISO 8601 dates [YYYY-MM-DD]
Right. So instead of stealing the password the intruder has to take the extraordinary step of stealing the key. And you've got an even worse problem in the general case when dealing with keys, because you have a hard time enforcing things like password expiration (just how long can someone use that stolen key to get into your system?)
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.
Windows has tons of local root exploits, which nobody is bothering to fix because they're too busy patching the remote exploits.
If Windows had a bug like this, it wouldn't be news. Microsoft hardly even tries to defend against such things. The only reason this is newsworthy is because Linux attempts to set a higher standard.
"
How many available kernel exploits have been identified over the last 5 years of Windows?
"
Sorry - Linux loses here. They don't call it a kernel exploit in windows. It's always an exploit in a separate subsystem instead.
Shhhh! Don't go telling everyone that the subsystem has access to every byte of RAM, and every I/O port, as that would spoil the fun.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
The worst Linux exploit of the year: an obscure kernel vulnerability that allowed one person to gain control of one box, disrupting one small OS group for a few days.
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?
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
This had been rumoured for several days before the actual announcement was made.
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.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
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.
With Linux Desktops being most popular in corporate settings, it's going to start being targetted by professional black hats, if it's not already. Security is a concern, even local exploits.
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.
When someone might yell at me, it has to be OpenBSD.
I disagree with your assessment. It depends on how the separation of mechanism and policy are implemented in the system. The "fear zone" you describe could only apply to a proprietary, binary-distributed system. Consider an environment where the system installer (call 'em the Admin) can install a public key at system setup time. Then, assuming the correctness of the signing system, the Admin can be assured that only properly signed binaries are run on that system. You'd want the build system and signing system to be off-network and physically secured.
That said I think signed binaries are a stopgap, not an OS-level security architectural feature. You'd have to refuse to sign any interpreters, or else modify all of them to run only signed code. Furthermore, this doesn't address questions of code injection into an already-running application.
1) It's not obscure anymore
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
an obscure kernel vulnerability that allowed one person to gain control of one box
This statement is missing a qualifier that is very important: 'That we know of so far'. How do you know that there is only one person who has the exploit? How do you know that said person only rooted the Debian boxes. How do you know that a larger group of people don't have this exploit and don't already own a flotilla of zombie systems? How do you know that your box isn't owned by such a group at this very moment?
It is these "obscure kernel vulnerabilities", that we assume no one has an exploit for, that are the most dangerous of all. Vulnerabilities of this type allow very highly skilled crackers (with intentions unknown) to own countless systems and do what they will for extended periods of time without detection. Debian thinks that this is weeks old. Suppose that this is only the cracker's latest version of the exploit and that previous versions haven't owned those machines for months or years?
Um no.
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
Sorry, I must have been vague, although some responses have grasped the main point of what I'm talking about.
The binaries are signed by the local root user (preferably on a separate box), at install time. The public key is installed in the kernel. This is about the root user preventing the box from running anything he did not install, not for the program's copyright owner or whoever else to control if it can run. As you can see, this has little to do with DRM, where another party controls what runs and what doesn't on your machine.
I'm also mainly talking about servers, on which ideally only a few trusted programs are installed. This lowers the signing overhead, and doesn't have a "power user" problem.
Since it is hard to coax an existing signed application into making your evil system call, the most likely target would then be the various script interpreters. That's a valid concern, and you should restrict yourself to those interpreters with a sandbox concept, and are well implemented.
The point is, by requiring two separate "points of failure", we are restricting the exploit to the intersection of time between the introduction and fixing of each bug. If no application bugs are known (to the cracker) at the time the kernel is vulnerable, you cannot exploit the bug. The reverse is also true.
I hope this helps clarify the point.
Imagine there is a buffer overflow in the kernel's brk() implementation that nobody knows about. What kind of security measures (other than finding the bug and fixing it) could prevent that buffer overflow from being exploited by an attacker?
When that question has been answered, go implement the answer, and this won't happen again.
Installed the Bubblemon yet?
What about 2.2.x series kernels, is there a similar patch?
I wrote some exploit code for the 2.4 kernel, it didn't work on 2.2, so maybe 2.2 never had this vulnurability.
Do you care about the security of your wireless mouse?