Slashdot Mirror

← Back to Stories (view on slashdot.org)

Local Root Exploit in Linux 2.4 and 2.6

Posted by michael on from the without-users-this-wouldn't-be-a-problem dept.

Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"

6 of 795 comments (clear)

  1. Re:Local vs. Remote by rewt66 · · Score: 4, Informative

    In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.

    A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.

  2. Fix is merged in mainline already by spurious+cowherd · · Score: 4, Informative
    See the message on The kernel mailing list

    raw diffs to for those brave souls who want them

    --

    Time flies like an arrow, fruit flies like a banana.

  3. Re:Copyright Poo Poo by _Sprocket_ · · Score: 4, Informative


    Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

    What's interesting is the preface that shows up on several lists:

    Hi all,

    first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiated by Stefan Esser from Ematters. The posting containing the plagiate will follow. Now I have been forced to release the full advisory however another disclosure timeline have been agreed on vendorsec. Sorry for the inconvenience.

    Followed by:

    Hi all,

    first of all I must comply about the handling of this vulnerability that I
    reported to vendorsec. Obviously my code posted there has been stolen and
    plagiarized in order to put the blame on Stefan Esser from Ematters and
    disturb the security community.

    I really apologize to Stefan Esser for the inconvenience and thank him
    for his cool reaction - the plagiarism did work.

    Further steps must be taken to investigate the security leak on vendorsec.
  4. Re:making APIs secure takes time by Alan+Cox · · Score: 5, Informative

    No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.

    Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.

  5. Re:What, no remote exploit?!? by Foolhardy · · Score: 4, Informative

    Shatter attack

    It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
    Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
    A creates a window on the interactive desktop (a big no-no) with a textbox in it.
    B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.

    First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
    Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
    MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
    Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.

  6. Unfortunately not the only one... by greppling · · Score: 4, Informative
    LWN article about some more local security holes in Linux published today. The advisory does contain some harsh words about Linux security as well.

    I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.

    And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.