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

Hurray for the Debian Security Team!

[pegr]

And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?)

Hats off to the Debian Security Team.

Re:How did they get in to run a userspace util?

[PPGMD]

I believe an earlier article said that it appeared that he sniffed a password to the box.

RTFA

[Stradenko]

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

[satyap]

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.

Re:Hurray for the Debian Security Team!

[Feyr]

actually, the exploit was known (found by andrew morton) but didn't make it to 2.4.22 in time. RTA

Re:Hurray for the Debian Security Team!

[Troed]

The bug had been found by Andrew Morton before, and was already fixed in 2.4.23. Thus, it wasn't unknown. It might even the because it was known that it was exploited aswell, I assume.

Quoting the Bugtraq post:

This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.

Re:Hurray for the Debian Security Team!

[Pros_n_Cons]

And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?) Hats off to the Debian Security Team.

from the article: "This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release." Good work by the Debian team in catching it before REAL problems ensued.
Hats off to Redhat and SuSe for reversing the code.

The kernel patch...

[lurp]

Here's the kernel patch that fixed the overflow in brk():
http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mm ap.c@1.32?nav=cset@1.1148.2.2 [bkbits.net].

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

Re:Time for better security.

[RedHat Rocky]

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.

OpenBSD

[Anonymous Coward]

openBSD did have one vurnability in the standard install, the openSSH issue of about a year ago.

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_channelall oc .txt

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.

Re:what kind of person...

[Smallpond]

What kind of person?
spammers [bbc.co.uk]

People who expect to make money by hacking systems and using them to send millions of unsolicited emails.

Re:A shift of focus

[pclminion]

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.

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.

Re:Time for better security.

[bahamat]

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.

Re:so are other distros possible infected?

[Nothinman]

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.

Re:Time for better security.

[keesh]

This wasn't a remote root exploit. It was a local root exploit, and OpenBSD has had several of those.

Re:what kind of person...

[ashridah]

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

Re:Will redhat provide an rpm???

[teg]

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 [redhat.com] these releases until the end of this year, so I'd expect them to.

Re:Time for better security.

[Spruce Moose]

Dude, it is. Check out Linux Security Modules [immunix.org] which has an implementation of SELinux.

It should be in the 'Security' menu option when you configure the kernel.

Re:The real question remains....

[mbanck]

There is also no mention of the original point of entry - which was said to be a sniffed password.

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

Re:Hurray for the Debian Security Team!

[cortana]

The bugfix has already been backported to the 2.4.18 kernel in Debian 3.0. From DSA-403-1 [debian.org]:

[The bug] 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.

Of course, had you read the article, you would already knew this. ;)

Re:A shift of focus

[John Whitley]

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.

Life is more complicated than that. Regular binaries can be run as: /lib/ld-linux.so /noexeced_path/myprog

Even locking this out, any available program that is itself an interpreter (e.g. Perl, etc.) can be used to run code. Assume that any attacker (or their scripts) know this and will leverage it.

I'm seriously beginning to think that we won't be able to achieve secure systems that reliably push the security problem to the social boundary until ground-up designs such as the Extremely Reliable Operating System [eros-os.org] mature.

You stupid fucktard

[Anonymous Coward]

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.

Re:Mysteries of good system administration

[eddy]

But still, what intrigues me the most is that they have found out that they were hijacked in the first place.

Because they suddenly started spewing oopses. RTFAs:

"On November 20 it was noticed that masters' kernel was generating a lot of oopses. While investigating this it was discovered that murphy was showing the exact same oops, which was an overly suspicious coincidence." -- Compromise details [wiggy.net]

Re:The kernel patch...

[smcv]

Since the Debian security advisory says the bug was found by Andrew Morton in September, my guess is that it was fixed in 2.4.23 as an ordinary bug, but nobody realised it was an exploitable security hole until a day or two ago.

Re:Well, well, well...

[Anonymous Coward]

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.

You can turn off RPC (aka DCOM) with this utility: http://grc.com/dcom/ [grc.com]

Re:A shift of focus

[John Whitley]

Seems like a stupid security hole.

This thread [debian.org] 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.

Proof-of-concept exploit code

[devine10]

Grab it here [linuxfromscratch.org]

2.4.23-pre7

[kbmccarty]

It was introduced in 2.4.23-pre7, disguised as "Add TASK_SIZE check to do_brk()" in the changelog [kernel.org].

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.

Re:How to decrypt a burneye encrypted exploit?

[Anonymous Coward]

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.

'Splot dat Kernel, d00d!

[t0ny]

Ah, another linux kernel exploit [securitytracker.com]. I sure [securitytracker.com] am glad [securitytracker.com] Im [securitytracker.com] running Windows!

Re:Shows the dangers of C

[penguin7of9]

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.

Re:How to decrypt a burneye encrypted exploit?

[wichert]

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.

Re:The kernel patch...

[maximilln]

I suppose you're a troll that wants me to quote direct lines of code from the Win32.dll and then diagram how they fit into the overall architecture. Yet you and I both know that I'd be legally liable for decompiling a proprietary Microsoft library without their express written consent if I did that.

You're saying you've seen the memory management parts of the Windows kernel. Have you seen it in the form of source code, decompiled? Or do you expect me to believe that you just watch it in active memory, in real time? In either case you would need to be a real technical programmer to have any clue what you're looking at. If you were a technical programmer then you wouldn't need me to tell you that the Windows kernel code is bloated and inefficient compared to a Linux kernel.

My Linux 2.4.23 kernel is still less than 1 mb. Six plugins later, each of around 100k, all of my hardware is accessible from the bash prompt. I've never seen a Windows system that can do that.

Re:Modular patch

[Anonymous Coward]

Why use LKM? Why not the (very impressive) method [phrack.org] the suckit-rootkit used?

Re:Wow, a Clippy joke

[AJWM]

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