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."
And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?)
Hats off to the Debian Security Team.
I believe an earlier article said that it appeared that he sniffed a password to the box.
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.
So it sounds like someone used a compromised user account to get in, ran a binary that exploited the bug, and got root that way. This is a local exploit, then.
http://linux.bkbits.net:8080/linux-2.4/diffs/mm/m
The patch is from 9 weeks ago... I wonder if the exploit writer got the idea from looking at the kernel changelog...
What kind of person?
spammers
People who expect to make money by hacking systems and using them to send millions of unsolicited emails.
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.
I don't mean to burst your bubble, bash Theo or OpenBSD, but I read Bugtraq daily, and I can't count the number of exploitable bugs reported in the OpenBSD kernel over the past few weeks, but it would probably take both hands and at least one foot. Linux however, iirc, had somewhere about 3. Given this info, I wouldn't be so hot to boast about OpenBSD's QA process.
I repeat, I'm not trying to bash OpenBSD. Just trying to bring a little balance to the arguement. OpenBSD is an excellent choice for an operating system, but it's designed by humans. Humans make mistakes.
The real flaw in what happened with this exploit is that there were no backport patches created. When the ptrace vuln came out I was able to patch my 2.4.19 and 2.4.20 systems right away, I didn't have to wait for the next release to come out in order to get a working fix.
This should trun into a plea to the developers, if a bug is discovered through the normal course of development that is potentially serious enough for older kernels, it should be brought out into the open and the fix backported.
This is a local exploit, it can't be used until you have a shell. Debian had the misfortune of having a developer's password stolen and used to get a shell, other distros would have to have similar problems with either passwords or network accessable services.
This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.
This wasn't a remote root exploit. It was a local root exploit, and OpenBSD has had several of those.
The kind who only has to read through LKML to realise that a potential root bug was discovered in september, but wasn't fixed in 2.4.22, and doesn't appear to have been backported to the kernel?
ashridah
Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.
Red Hat is supporting these releases until the end of this year, so I'd expect them to.
This has been confirmed in an earlier post.
So which individual was sending passwords in the clear?
Exactly how the attacker managed to get the password is unknown so far. It suffices to say that he got the password and thus access to the machines.
And if it's a Debian developer who's done this
There are far easier ways for Debian Developers to mess up Debian. That's why there are the tough entry exams, aka the Debian New-Maintainer process.
Michael
Because they suddenly started spewing oopses. RTFAs:
Belief is the currency of delusion.
You can turn off RPC (aka DCOM) with this utility: http://grc.com/dcom/
Seems like a stupid security hole.
This thread 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.
Grab it here
It was introduced in 2.4.23-pre7, disguised as "Add TASK_SIZE check to do_brk()" in the changelog.
If you aren't averse to compiling your own kernel, the fix is a really easy two line patch. Just add the following to mm/mmap.c at line 1047 (immediately after "if (!len) return addr;")
if ((addr + len) > TASK_SIZE || (addr + len) < addr))return -EINVAL;
I'm enjoying the thrill of compiling patched kernels on two different machines as I write this. Thank goodness for Debian's make-kpkg.
- Kevin B. McCarty
I hate to break it to you but that runtime saftey isn't magic, it's implemented by an unsafe runtime somewhere.
You're on the right track. Now, if you think a little further along the same lines, you'll see that you are much better off implementing safety once, in a single place in the runtime, rather than trying to implement it in user code in 6 million lines of kernel code. It's called "reuse", "abstraction" and "encapsulation", and it's as important for safety as it is for anything else.
In some situations runtime saftey can cause a serious performance hit that at a kernel level will significantly slow the entire system.
You're missing the point. Modula-3 and C# don't force you to write safe code everywhere, they give you the option to choose. (Not that it is relevant to this discussion, but the overhead of enforcing runtime safety strictly is also small.)
Safe runtimes are great for high level apps but they aren't a magic bullet.
That's why languages like Modula-3 and C# offer both safe and unsafe constructs. The problem with C and C++ is not that they have unsafe constructs, which systems programming languages need, but that they don't separate unsafe and safe constructs.
UNF burninhell was indeed used. The problem was that the binary was (probably manually) fudged so that burninhell would not recognize it as a proper burneye encrypted file. Robert had to manually fix that before burninhell would accept the file and started to brute-force guess the password used.
What ever happened to Scrappy Doo?
You need to watch the recent (well, couple years now I guess) Scooby Doo live-action/CGI movie. It explains all.
(And my excuse is that I have kids -- I rented the DVD for them. That's my story and I'm sticking to it.)
-- Alastair