Kernel Exploit Cause Of Debian Compromise 673
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."
A shift of focus (Score:5, Interesting)
Will redhat provide an rpm??? (Score:5, Interesting)
Re:Time for better security. (Score:3, Interesting)
Strictly true, but there has been one remote hole and many local root holes. Remote hole + local root hole = remote root hole.
I'm not denying OpenBSD's superiority, but its security record isn't that much better than that of the other BSDs.
Re:Time for better security. (Score:5, Interesting)
The strength of OpenBSD is that people continously audit the code and implement preventive stuff like privilege separation to reduce the risks in case of a vulnerability.
On the other hand, the code of BSD kernels is a real mess. Some parts are really tricky, with glue between historic and new code and a lot of ugly, possible unsafe macros everywhere. The Linux kernel framework is way cleaner and more robust. When something goes wrong in a kernel thread, it can almost always properly recover and not just go to panic().
And Linux has also some barriers like SELinux that theorically renders uncommon situations not exploitable. Theorically, because there can still be bugs in SELinux or other parts of the kernel that would bypass it.
The "barriers" approach, although described as useless by some people is, in a real world, very efficient. Grsecurity (or recent OpenBSD with PaX and co) and SELinux make it very difficult to write reliable exploits. Still if an exploit would work, it will only work after having filled gigabytes of log files, giving a change to system administrators to take an action on time.
The cons of the "barriers" approach is that it cures the implications of a problem, not the cause. The bug is still there, but instead of being exploitable to execute arbitrary code, it crashes the process (eventually immediately restarted with a tool like Monit or Supervise).
The OpenBSD auditing approach aims at curing the bug itself, thus not causing any crash.
Both approaches are actually complementary, but still not 100% efficient.
The only way to make reliable and secure (even from a theoric point of view) is to prove the code. Unfortunately it's not a trivial task and it can't be made upon an existing unix-like base.
But if you never heard about it, have a look at the very promizing EROS Project
http://www.eros-os.org/
Re:Time for better security. (Score:2, Interesting)
Recently multiple servers of the Debian project were compromised using a Debian developers account
You would notice it was not a remote exploit. OpenBSD has had its share of local exploits lately too.
Don't get me wrong, OpenBSD is good stuff and has a great way of approaching security. But in this case, it could have been compromised just the same.
The real question remains.... (Score:4, Interesting)
The question remains, who is targetting Open Source? With this being the latest in several high-profile attacks, the evidence would suggest a determined effort is under way to put egg on the Open Source face.
Who? Why?
Re:Time for better security. (Score:5, Interesting)
You know, when I install a computer, I consider the "install" to be the files installed on my hard drive. "/bin/ls" is part of the "install." "/sbin/ifconfig" is part of the "install." "/usr/libexec/ftpd" is part of the "install."
Apparently, however, the OpenBSD developers disagree. Something has to actually be running to be part of the "install." Thus, by their definition, none of those programs are part of the "install."
Good thing, too. Because
Jeremy
Well, well, well... (Score:0, Interesting)
I know I risk being downmodded, but I just had to say this. I get flamed for being a so-called "Microsoft shill" constantly for pointing out the obvious--operating systems are as secure as their admins/makers. It's not a religion, folks. Here is a buffer overflow exploit embedded right in the kernel.
It'd be nice if the community showed a little humility, but, of course, next week this story will be forgotten and drowned out by repeat dupes of some "Microsoft hole" that is really an executable attachment ran by Outlook users or something.
Nothing ever changes, but at least it's good to know the developer community around Linux knows their software is not perfect and constantly strives to make it better. It's all those vocal "anti-M$" trolls that have called Slashdot (and OsNews.com) their home who look pretty stupid right now.
What comes first? (Score:2, Interesting)
Movie Mirror (Score:1, Interesting)
I verified it, it's the right one.
Double standards (Score:3, Interesting)
But when Linux has a kernel exploit and is patched, people will point to that--"But it's already patched! Download the new kernel!"
Re:This smells like the work of... (Score:5, Interesting)
Why it continues to be modded up as "Insightful" every time, I'll never know. Honestly, what insight was gleamed by this post?
Re:Well, well, well... (Score:1, Interesting)
Re:The kernel patch... (Score:2, Interesting)
I'm more concerned about the security of the computing world as a whole. The Windows kernel is significantly more bloated and full of overlapping loops, crappy memory management, and all sorts of extra junk that just doesn't need to be in a kernel. With that in mind--how many kernel level exploits do you suppose exist in Windows? Knowing the lack of punctuality with which MS addresses the issues what do you suppose the proportion of cracked computers across the globe is?
It'd be a perfect escape route for all of those people who have been accused of insider trading: "I never told them anything. They must've been using an unknown Microsoft Windows exploit to monitor my private transactions in real time."
Not yet (Score:5, Interesting)
I just checked the current Red Hat 9 kernel source RPM and it does not have the patch yet [kernel-2.4.20-20.9.src.rpm]. I would expect a new kernel to show up soon though....I hope. The supposed patch which fixed this was in do_brk() [a /. comment further down provides the bk url]
Re:A shift of focus (Score:5, Interesting)
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:Well, well, well... (Score:2, Interesting)
It's not really a fair polling system, though. Microsoft can spend millions to squelch the public notification of any severe exploits if they need to. The fact is that unless we're actually the ones writing exploits we'd never know.
There are some basic principles which point towards secure code. Proper flowcharting. Proper logic design. Efficient code. Time and again Microsoft has demonstrated its disregard for proper flowcharting and logic design (eg. "We have a deadline to meet. Make that code work any way you can so we can put this sh*t on the shelves and sell it!") and the code is blatantly bloated. Where Microsoft fails on all three criteria Linux makes a comprehensive effort of achievement. It may not be very technical or factually based but, in the absence of any real or reliable numbers, it's the best benchmark to use to compare the two.
What Crow? (Score:5, Interesting)
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:A shift of focus (Score:3, Interesting)
The reason this isn't done more often, is that it's a bit of a hassle for the power users.
Mysteries of good system administration (Score:5, Interesting)
Honestly, if I were smart enough to sniff a password, I'd also be smart enough not to let anyone know I've sniffed. Still, the folks at Debian were able to blame the unpriviledged account part on a sniffed password. Now how do you gain evidence for something like that?
Likewise, if I'd be smart enough to gain local root access by flipping the kernel, I would also be smart enough to ditch the binary with which I did that. Nevertheless, though after a thorough research, the Debian team has found the binary and managed to understand its potentials.
But still, what intrigues me the most is that they have found out that they were hijacked in the first place. Now I have a rock solid system for that at home, which is an 8 Mb RAM Sparc Classic, which starts to trash so hard at the least of activity, that I would well be alarmed if someone else than me was using that machine for whatever purposes. But as I may assume that those Debian machines weren't that low-end, how could you ever expect to know when you have been exploited?
Re:Mysteries of good system administration (Score:3, Interesting)
Re:A shift of focus (Score:4, Interesting)
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
Re:Well, well, well... (Score:2, Interesting)
1. It's a timyurl link(ie. probably goatse), and
2. The description sounds like goatse as well.
Re:A shift of focus (Score:3, Interesting)
In a life long ago, I used a Multics system which was running AIM, the kind of military-grade security that's in NSA's Linux, and couldn't even tell it was in place. The sysadmins could, but us developers only saw the usual group-like facilities.
This is prefectly reasonable for a machine that's hosting my current personal projects along with my homework (;-))
--dave (DRBrown.TSDC@HI-Multics.ARPA) c-b
I think BSD is better written... (Score:4, Interesting)
Having looking at both sources for linux and BSD, I think that BSD is better written in total. That isn't to say that there are no ugly parts in BSD, or no nicer parts in linux, just as a whole BSD is nicer.
To save you some time I present the next 3 replys to this post.
Is not
Is too
Is Not
Re:Well, how about 570 days (Score:2, Interesting)
[root@balder toor]# uname -a;uptime
SunOS balder 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-250
2:42am up 864 day(s), 7:26, 2 users, load average: 0.07, 0.06, 0.05
[root@balder toor]#
What release did it APPEAR? (Score:3, Interesting)
How to decrypt a burneye encrypted exploit? (Score:3, Interesting)
Here [securiteam.com] is a tool that may have been used.
For the Security ANAL. (Score:3, Interesting)
There is no such thing as Utopian security. IF your hooked in your vulnerable. period.
I don't know why people make such a big deal out of security for computers. Think about it. In real life things aren't very secure, I could break into most homes and steal things, or break things if i wanted to. but I don't. Why ? the threat of punishment, and not-so-common sense.
If your a person who has deviant desires why wouldn't you break into a house ? VISIBLE security that would make punishment (ie jail) more likely would be the major reason. its not that the house is burglar proof, its that society has come to deal with criminals in the most effective way possible, and it doesn't usually hinder the average person. I think this is what we are lacking with computers, a clear cut enforcer. a "police" type body that could enforce laws such as "cracking and entering". and programs similar to an ADT-type of alarm system. We need a real solution. and Utopian code is not it. and making absurd laws are not it either.
Re:A shift of focus (Score:3, Interesting)
I suggest you consider the solution again. The underlying bug (kernel buffer overflow, for instance) doesn't disappear. It's just much harder to exploit. In an unsigned system, it's a pretty trivial task to download a binary that makes the "proper" kernel call. If a compiler is installed, you can even just type in a program.
On the other hand, on a signed system the only way is to get an existing signed binary to make a bad system call. That's still possible, but now we're talking about two bugs, one in the kernel and a corresponding one in an user space program. Given that a dedicated server should be running the smallest number of the most trusted programs, this may not be such an easy task, and at the very least may slow down the attacker.
So what are these multitude of ways you can run an arbitrary application?