Slashdot Mirror


Weakness In Linux Kernel's Binary Format

Goodfellas writes, "This document aims to demonstrate a design weakness found in the handling of simply linked lists used to register binary formats handled by the Linux kernel. It affects all the kernel families (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in kernel space that can be used by malicious users to create infection tools, for example rootkits. Proof of concept, details, and proposed solution (in PDF form): English, Spanish.

18 of 281 comments (clear)

  1. 1 meg PDF? by Lehk228 · · Score: 4, Funny

    yes, a pdf linked from slashdot will last a long time...

    oh wait it's already gone

    --
    Snowden and Manning are heroes.
  2. And? by ledow · · Score: 4, Informative

    Although any auditing is welcome and they may be a problem here, the fact is that it's hardly news and not exploitable. The reports says itself that you have to be root to exploit it. It's already game-over. Yes, look for these sorts of things and find them but it's hardly worth the shock-factor of "Massive Hole Found In Linux" panic headlines.

  3. Too bad you have to be root. by czehp · · Score: 5, Funny

    OMFG! I have a security flaw... but you have to be _root_ to execute it! AHHHHH It's the end of the world!

    I discovered a new one too... if you run rm -rf / as root you'll bork your system!

    We should all go back to windows, where rm doesn't exist ^_^

    1. Re:Too bad you have to be root. by Lehk228 · · Score: 4, Informative

      that is more due to limitations on NTFS and FAT* than self protection

      unix filesystems can delete an in-use file and only physically remove it when it is no longer in use, windows cannot do that. hence having to reboot for so many updates and some configuration changes (such as changing host name)

      --
      Snowden and Manning are heroes.
  4. This is so not serious by Spikeles · · Score: 5, Informative

    For those who won't read it..

    Basically there is this table that contains a list of handlers for the various exes, if if a handler returns a failure the loop that parses the table will stop iterating. If you insert a kernel module first you can take control of all executable types b4 any other handles get to handle it.

    BUT...It requires root access and wont work on SELinux. This is a serious how? I mean if you have root access, then the entire system is compromised already.

    --
    I don't need to test my programs.. I have an error correcting modem.
  5. Probably none. by SanityInAnarchy · · Score: 4, Informative

    Depends on the friends and the distro, but let's see. Debian prompts you to set up an ordinary user/password, as well as a root password. Gentoo does the same, only via documentation, not an installer. And Ubuntu, the distro most friends would send noob-friends to, does not set up a root password at all -- all root access on Ubuntu has to go through sudo.

    Most Windows/IE attacks don't require you to even have local access, let alone root.

    --
    Don't thank God, thank a doctor!
    1. Re:Probably none. by SanityInAnarchy · · Score: 5, Insightful

      This argument has been tried over and over again. It is prohibitively difficult to make an attack like this work.

      The only way I know of to change the user's password requires the user to type their password.

      Yes, you could use a keylogging-type attack, but sudo does make this prohibitively slow unless you really know what you're looking for. Even if you do, you still have to wait for the user to answer a sudo prompt.

      You could theoretically crack the user's password from the password hash, but this is both time consuming and impossible -- /etc/shadow is not readable by ordinary users.

      Beyond this, you could try a phishing attack -- put up your own sudo-like prompt and hope they bite -- but that's about it.

      How would you propose to remedy this situation? Do you switch to another VT or use a magic sysrq key everytime you become root?

      --
      Don't thank God, thank a doctor!
    2. Re:Probably none. by TeraCo · · Score: 4, Funny
      but this is both time consuming and impossible

      Phew, I'm glad it's not just impossible. That might have been risky.

      --
      Not Meta-modding due to apathy.
    3. Re:Probably none. by smash · · Score: 4, Informative
      Knowing about how linux works doesn't exclude you from the set of potential ubuntu users.

      I've adminned Linux since 1996 (1996-2001 as an ISP sysadmin, 2001-2004 for corporate mail, proxy, IPSec gateway, etc), yet most of the time these days for a desktop I install/use/recommend Kubuntu. Why? Because it just works for the most part. I've been through the rolling my own distro from scratch, building all my stuff from source games and to be honest, I have more important things to do these days :)

      Sure I'll muck around with that sort of thing from time to time, but when I just want to get work done, *ubuntu is quick and easy.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  6. Mirror by paulproteus · · Score: 4, Informative
    --
    |/usr/games/fortune
  7. They'll fix it. by SanityInAnarchy · · Score: 4, Interesting

    They'll fix it out of pride, and because it's the right way to do it. That's assuming this is actually a flaw -- a buffer overrun or something. For instance, if it's some retard saying "Oh cool, I can install a rootkit by changing a couple of bits here in /dev/kmem", then no, they won't fix it. But if it only requires access to, say, the binfmt_misc filesystem, then it is a bug.

    And it's important to remember things like this when you see Symantec, Microsoft, and others trying to spread FUD about Linux security. If anyone cares about this bug at all, even just as a matter of keeping the code neat, it will be fixed -- but it will also drive up the numbers of "Linux exploits patched recently". Always, always, always look at the relative severity of the exploits.

    --
    Don't thank God, thank a doctor!
  8. Re:What about other ELF systems? by IWannaBeAnAC · · Score: 4, Informative
    With the caveat that I cannot RTFA as it is slashdotted, if the summary is in any way accurate then it will not affect the BSD's or Solaris. SCO I don't care about, especially as it would only affect them if they stole the relevant code from Linux in the first place.

    Linux has a feature that allows you to register a new binary format loader. Of the traditional formats, ELF is the most common, a.out is ancient, I don't think I've ever seen an a.out executable on a Linux machine). But on Linux, for example, if you wanted java programs to run automatically when you execute them then you could install a loader for java files that runs them through the interpreter/jvm.

    I don't know which other unixes have this capability, but IIRC Linux was the first so it follows that any other implementation is architecturally independent, so shouldn't share the same implementation flaws.

  9. simply by Anonymous Coward · · Score: 5, Funny

    simply linked list

    As opposed to difficultly linked lists?

    1. Re:simply by Penguinoflight · · Score: 4, Informative

      Most CS types would say that SLL is Singly Linked List. The construct allows for references to next, but not to previous.

      --
      "And we have seen and do testify that the Father sent the Son to be the Savior of the World"
      1 John 4:14
  10. Weakness In Linux Kernel's Binary Format by nick_davison · · Score: 5, Funny

    A weakness in the binary format? OK, who's to blame here, the ones or the zeroes?

    You'd have thought they'd have caught this sooner. It's not like it's that long of a list to exhaustively test.

  11. Re:What about other ELF systems? by Tyger · · Score: 5, Informative

    I'd say this is just a specific case of inserting malicious code into a kernel level linked list. Most kernels have linked lists meant to be accessed by drivers. I've actually done something very similar in Solaris using the SVR4 STREAMS driver model. I created a STREAMS module that inserted itself into the TCP stack in such a way that it was totally invisible, but got all data and control commands passed through it. (Excpet I wasn't writing malicious code. In that case, I was hiding it from any potential hackers, as well as applications that might break if the STREAMS modules aren't loaded like they expect.) There are other places it could be inserted for malicious purposes aside from the network stack, though. (Not that the network stack isn't a bad place to be for someone who wants to do some damage, but it doesn't help with hiding rootkits. It would be more useful as a rootkit payload.)

    I'm sure BSD has a linked list that could be similarly exploited. It won't have the same capabilities as the Linux binfmt one, but it will have it's own set of things it could be used for.

    However, I agree with other users. In a monolithic kernel, once someone has root and can load kernel drivers, or even access kernel memory, all bets are off. The only possible system I can see not being exploitable in such a way would be a pure microkernel architecture with memory protection, none of which I can think of off the top of my head. Mach still has loadable modules. QNX is closer but even QNX lets you register code to be called as an ISR from the kernel, and at that point you have full access to the kernel memory, and you are even conveniently passed a pointed to some kernel data structures so you don't have to try and figure out kernel symbols.

    The point is, once you have root, there are any number of ways to compromise the system and hide your exploits. It's good to have the information about as many different ways as possible out in the open, but it's hardly alarming news that there's yet another discovered.

  12. Pointless by ZxCv · · Score: 4, Insightful

    .... but that's much better than the risk of getting owned by some kernel module. ;-)

    If someone is loading kernel modules on your machine, you've already been owned.

    --

    Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
  13. Nothing to see here, move along! by Lost+Found · · Score: 5, Insightful

    As the first person who replied to this announcement in LKML, I will certify that this "weakness" is pretty silly. Here's what the claim is:

    1. You must be root
    2. You must be able to load an arbitrary kernel module
    3. You write an arbitrary kernel module that calls a kernel function to install yourself as an "binfmt handler"
    4. That kernel module is put on the _front_ of the list instead of the _end_
    5. Every program that runs now ends up calling your "binfmt handler" first

    Their solution:

    1. Put it on the _end_ of the list instead of the _front_ when it registers itself, that way it only runs if the binfmt cannot be identified...

    This is literally just as stupid as discovering that you can call fork() and exec() with an argv of "/bin/rm", "-rf", "*". Oh no, everyone must patch their systems! Seriously, anyone who can load an arbitrary kernel module could technically do _anything_, including replace the whole kernel image from the inside out!