Slashdot Mirror

← Back to Stories (view on slashdot.org)

Kernel Exploit Cause Of Debian Compromise

Posted by simoniker on from the slightly-disturbing dept.

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

11 of 673 comments (clear)

  1. RTFA by Stradenko · · Score: 5, Informative

    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.

  2. So it sounds like.... by satyap · · Score: 5, Informative

    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.

  3. Re:Hurray for the Debian Security Team! by Troed · · Score: 5, Informative

    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.

    --
    it's in my head
  4. The kernel patch... by lurp · · Score: 5, Informative
    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.

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

  5. Re:A shift of focus by pclminion · · Score: 5, Informative
    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.

  6. Re:Time for better security. by bahamat · · Score: 5, Informative

    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.

  7. Re:so are other distros possible infected? by Nothinman · · Score: 5, Informative

    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.

  8. Re:what kind of person... by ashridah · · Score: 5, Informative

    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

  9. Re:A shift of focus by John+Whitley · · Score: 5, Informative
    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 mature.
  10. Re:A shift of focus by John+Whitley · · Score: 5, Informative

    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.

  11. Re:How to decrypt a burneye encrypted exploit? by wichert · · Score: 4, Informative

    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.