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...
Perhaps you should check www.openbsd.org:
"Only one remote hole in the default install, in more than 7 years!"
Never mind that the default install is basically useless.
Anything is possible given time and money.
openBSD did have one vurnability in the standard install, the openSSH issue of about a year ago.
l oc .txt
according to the site:http://www.openbsd.org/
Only one remote hole in the default install, in more than 7 years!
http://www.openbsd.org/advisories/ssh_channelal
But I suppose you could argue that openSSH, even if it was sponsored in part by the OpenBSD team, isn't really part of the OS, or at least part of the Kernal.
Of course, this is far better than just about any other OS.
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.
It should be in the 'Security' menu option when you configure the kernel.
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
11/29/2003 3:45 - SUSE: BIND Negative cache vulnerability and many others
11/29/2003 3:37 - FreeBSD: Bind Negative-cache DOS vulnerability
11/28/2003 12:30 - Trustix: bind Cache poisoning vulnerability
These three vulns are the same thing, regarding one application which may or may not be running on a particular Linux distribution. You can't count these as separate incidents. Going over your list, fully half your "separate incidents" are actually duplicates.
Likewise, let's see how many of these could lead to a root-level compromise...:
Gentoo: Etherial multiple vulnerabilities: Hmm.. maybe this one (but you're probably already running this particular diagnostic utility as root anyway). Incidentally, this is a third-party application that is not included as part of Linux. Ergo, no go.
Gentoo: Libnids remote code execution: Hmmm.. perhaps. It is doubtful, however. You're more likely to just corrupt and drop your connection. Notice the use of the word "probably". That means "possible, but not seen in the wild; patch before someone does come up with a method for attack". Compare and contrast against most (all) Microsoft announcements.
Unfortunately for you, none of the other issues presented here can lead directly to root-level compromise. Instead, an administrator suffering these exploits would simply need to restart the particular service (as opposed to the almost universal need for a wholesale Windows reboot). These issues fall mostly under "irritating" and not "fatal".
In short: BZZZZZZZZZZT. Try again.
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
As the maximum possible encryption used in burneye is pretty strong (SHA1 hashed passphrase + SHA1 hashed system fingerprints, RC4 as cipher) they must have either used a weak passphrase, or the passphrase has been recovered from other system or tty logs. Or then, they used no passphrase at all, in that case it takes a 10 minute journey to unpack the binary.
Ah, another linux kernel exploit. I sure am glad Im running Windows!
Manipulate the moderator system! Mod someone as "overrated" today.
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.
Why use LKM? Why not the (very impressive) method the suckit-rootkit 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