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."

Comments

A shift of focus

[chrysalis]

It's fun to see how security research shifted from applications to kernels lately.

Re:A shift of focus

[GlassHeart]

The "nice" thing about kernel exploits (from a cracker's perspective, of course), is that it doesn't matter what sort of userland software is running on the machine -- if you can get local access, by whatever means, it is very easy to boost yourself to root.

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

[Querty]

That's a silly reason for plugging DRM. Simply mount all user-writable space with option "noexec" and you have the same level of security.

The reason this isn't done more often, is that it's a bit of a hassle for the power users.

Re:A shift of focus

[BokLM]

For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries.

It's also possible to use SELinux. 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 /bin/sh ... it would be blocked by the kernel. It's also possible to tell what syscalls are allowed for a program.

Re:A shift of focus

[davecb]

It may be overkill for some very small boxes, but a good barrier between my web server and my work account is not to be sneezed at.

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

Re:A shift of focus

[GlassHeart]

Digital signatures don't help much, there is a multitude of other ways to mmap/read an executable into memory and run it.

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?

Will redhat provide an rpm???

[cybrthng]

Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.

Re:Time for better security.

[Free Bird]

[OpenBSD's] security review process has yet to permit a remote root compromise in a standard install.

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.

[chrysalis]

Well... yes... and no.

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.

[jgreene_81]

If you had read the article...

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....

[RedHat Rocky]

Any word on the parties behind the attack?

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.

[jemfinch]

While OpenBSD has not shared in the commercial success of Linux, it does have one area of technical superiority: its security review process has yet to permit a remote root compromise in a standard install.


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 /usr/libexec/ftpd has sure as hell had a remotely-exploitable root hole.

Jeremy

Well, well, well...

[Overly Critical Guy]

I get flamed and downmodded constantly for my sig. And yet, here is an outright exploit in the very Linux kernel itself. Open Source software is as insecure as any other large application. How does that crow taste?

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.

Re:Well, well, well...

[Anonymous Coward]

It should be noted that this was not remote exploit like all the recent MS exploits. This still requires access to the box.

Re:Well, well, well...

[maximilln]

Before you demand humility from the Open Source community you might want to check relative numbers. How many available kernel exploits have been identified over the last 5 years of Linux? How many available kernel exploits have been identified over the last 5 years of Windows?

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.

Re:Well, well, well...

[yourmom16]

I haven't clicked the link in your sig because:
1. It's a timyurl link(ie. probably goatse), and
2. The description sounds like goatse as well.

What comes first?

[golan]

The patch is from 9 weeks ago... I wonder if the exploit writer got the idea from looking at the kernel changelog...

That's something I've always been thinking about. Do crackers follow security announcements and changelogs and stuff like that to make exploits or are the patches made because of a cracker that discovered a vulnerability and used it to crack a box? Are there any stats about this? Any info?

Movie Mirror

[Anonymous Coward]

http://www.varnamognagare.com/calle/runken.mpeg

I verified it, it's the right one.

Double standards

[Overly Critical Guy]

But according to most admins here, they don't immediately apply Microsoft patches, so they can do their little "tests" to make sure everything keeps running fine.

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...

[Overly Critical Guy]

Every time there's some sort of compromise on a high-profile Linux network, some idiot tries to implicate Microsoft on the basis of idle speculation.

Why it continues to be modded up as "Insightful" every time, I'll never know. Honestly, what insight was gleamed by this post?

Re:The kernel patch...

[maximilln]

You can bet your bottom dollar that people who write exploits spend more time monitoring changelogs than they do actually writing exploits.

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

[dmeranda]

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]

--- 1.31/mm/mmap.c Fri Sep 12 06:44:06 2003
+++ 1.32/mm/mmap.c Thu Oct 2 01:18:19 2003
@@ -1041,6 +1041,9 @@
if (!len)
return addr;

+ if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+ return -EINVAL;
+
/*
* mlock MCL_FUTURE?
*/

What Crow?

[IBitOBear]

Exactly what crow is that?

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".

Mysteries of good system administration

[Pflipp]

What I find intriguing is that those fine folks at Debian have come this far at detecting the exploit and tracking down the who's and why's (with the who's still being left undecided for the public, anyway).

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

[Pflipp]

OK, I was afraid that this part would be misunderstood, but: how could you ever expect to know that you have been exploited? E.g., as in: how big is the chance that an average Debian (or other) machine at any time (other than now, of course) has been exploited without anyone being aware? And how do you expect to prevent this situation?

I think BSD is better written...

[bluGill]

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

[g0sub]

Screw Linux! :)

[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?

[whoever57]

What about 2.2.x series kernels, is there a similar patch?

How to decrypt a burneye encrypted exploit?

[TimFreeman]

The article saith:

Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit.

Does anyone have an idea how he managed to do that? The only approach I can imagine is a dictionary attack.

Here is a tool that may have been used.

For the Security ANAL.

[1lus10n]

Say it with me ....

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.