Forgot your password?
typodupeerror
Security Linux

Hole In Linux Kernel Provides Root Rights 274

Posted by Soulskill
from the everything-old-is-new-again dept.
oztiks writes with this excerpt from The H: "A vulnerability in the 32-bit compatibility mode of the current Linux kernel (and previous versions) for 64-bit systems can be exploited to escalate privileges. For instance, attackers can break into a system and exploit a hole in the web server to get complete root (also known as superuser) rights or permissions for a victim's system. According to a report, the problem occurs because the 32-bit call emulation layer does not check whether the call is truly in the Syscall table. Ben Hawkes, who discovered the problem, says the vulnerability can be exploited to execute arbitrary code with kernel rights. ... Hawkes says the vulnerability was discovered and remedied back in 2007, but at some point in 2008 kernel developers apparently removed the patch, reintroducing the vulnerability. The older exploit apparently only needed slight modifications to work with the new hole."
This discussion has been archived. No new comments can be posted.

Hole In Linux Kernel Provides Root Rights

Comments Filter:
  • by Anonymous Coward on Saturday September 18, 2010 @08:23PM (#33623270)
    That's why those of us in the know stick to 8-bit Linux kernal.
  • by Anonymous Coward on Saturday September 18, 2010 @08:23PM (#33623272)

    I mean this is what, the third 'reverted' security patch we've heard about in the recent past that needed replacement?

    Maybe it's time to seperate out core kernel code and the arch specific stuff into seperate modules with seperate administration. Git would make this easy, so why aren't we seeing it done?

    • by siride (974284) on Saturday September 18, 2010 @08:26PM (#33623294)

      You're talking about git submodules and I'm gonna go ahead and guess that the answer you'll receive from the kernel folks about that is a big fat "no". Maybe if Git had usable project hierarchies, things might be different.

      Also to note: even Git can't fix stupid policy or stupid programming decisions.

      • by Nikker (749551)
        I always like it when other programmers complain they can't do something because of a programs behavior, gives me this warm fuzzy feeling.
        • by siride (974284)
          Unfortunately, it's often prohibitive for you to fix every other piece of software out there that doesn't work the way you want it to, especially when it's quite enough just to deal with your own software.
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Also, since the kernel is fairly 'well documented', we should be able to tell WHO is responsible for removing the patch, and reintroducing the vulnerability.

        Perhaps, we could ask them why such a thing happened, and whether the linux community needs to backtrack this specific dev/s, kernel patching to date.

        You want to talk about 'quality control' in the open source world, here it is right in front of us. Will it be done properly and thoroughly?

        • by Jurily (900488)

          You want to talk about 'quality control' in the open source world, here it is right in front of us. Will it be done properly and thoroughly?

          You mean by ridiculing the person who made a mistake in front of the whole world? Patch your own fucking kernel if you're so damn smart.

          • Re: (Score:3, Informative)

            by jeremyp (130771)

            I don't believe ridicule was mentioned.

            Anyway, no matter how painful it might be for the person who reverted the patch, the issue does need to be investigated in order to find out how to detect other instances and how to stop it from happening again.

    • Re: (Score:2, Insightful)

      by mysidia (191772)

      Yeah... at this point i'm wondering if there are some kernel developers who like there to be security bugs in the kernel?

      Why else would they revert the security patch? Polticial reasons? They don't like the fix?

      Or perhaps some of the kernel developers a black hats working covertly, and the 'fixes' cause them problems exploiting their secret bugs.......

      • > Why else would they revert the security patch?

        Because they made a mistake. People do that.

        • by wampus (1932)

          Do they have code reviews in Open Source land? We sure as hell do in boring business software world. Tends to catch shit like this.

        • Re: (Score:3, Insightful)

          by mysidia (191772)

          1 reverted security patch is a mistake.
          2 reverted security patches is a major mistake
          3 unintentionally reverted critical patches in 6 months is a pattern of major fuck-ups.

          I'm not saying people don't make mistakes. Part of the purpose of version control is to prevent such accidental reversions.

          A pattern of reverting security changes, and not detecting those reversions before the software goes to world-wide release is pretty inexcusable, in most reputable development firms... people would get fired o

          • Re: (Score:3, Informative)

            by Anonymous Coward

            The offending patch was authored and committed by a Redhat developer. Since this guy made his own company's product insecure for their clients, I'd say that Redhat could very well fire him. Whether they will or not depends on the company. Besides, do you know of a Microsoft (or any closed source software company) employee being fired based on their coding vulnerable software? How about a CEO being fired for selling vulnerable software to the public? Where's the accountability there?

          • Errare Humanum est (Score:3, Insightful)

            by cyrilc (126593)

            The fact that because we can't fire developers makes it an incentive to bad coding practices is not an argument:

            for some people (esp. Linux developers where pride is an important fuel to their creativity), being pointed out in public by such bad behavior is much worse than being fired in the equivalent closed software company.
            Moreover, you will never know how many developers in a closed model had turned a simple patch into a remote exploit and if the culprit was really fired afterward esp. if it's a core de

  • Patch (Score:5, Funny)

    by Anonymous Coward on Saturday September 18, 2010 @08:25PM (#33623282)

    For those who compile from source, here is the patch:

    ---kernel.c
    +++kernel.c
    @@ -1,1 +1,1 @@
    - void goatse(long cx) {
    + void goatse(int cx) {

    The change from long to int closes the massive hole.

  • by Anonymous Coward on Saturday September 18, 2010 @09:10PM (#33623486)
    Root is a privilege, not a right.
  • Patch (Score:4, Funny)

    by Frankie70 (803801) on Saturday September 18, 2010 @09:13PM (#33623500)

    You can get a patch here [microsoft.com].

  • by Athanasius (306480) <slashdot@nosPam.miggy.org> on Saturday September 18, 2010 @09:23PM (#33623548) Homepage

    If you know how to drive git you could try applying these:

    • commit eefdca043e8391dcd719711716492063030b55ac:
      x86-64, compat: Retruncate rax after ia32 syscall entry tracing
    • commit 36d001c70d8a0144ac1d038f6876c484849a74de:
      x86-64, compat: Test %rax for the syscall number, not %eax

    there is a workaround of disabling 32bit binaries (I'd paste a link if Google Chrome dev channel would let me... for some reason I can only paste into /.'s comment box before I've typed anything else, I'll follow-up with it), but of course you may need them depending on what your machine does.

    There's also a separate issue that also gives local root, fixed by:

    • commit c41d68a513c71e35a14f66d71782d27a79a81ea6:
      compat: Make compat_alloc_user_space() incorporate the access_ok()

    I'm running a kernel base don 2.6.35.4 but with all 3 of those commits applied (note the last one tries to modify an arch/tile/ file which doesn't exist in 2.6.35.4, just ignore that) and can confirm that neither exploit works.

  • Okay, I get that when system calls are made to 32 bit whatever, bad things could happen. But why would there be anything 32 bit there at all? Shouldn't everything that is running on a server be compiled for 64 bit? I gotta say, this is a good reason to hate 32 bit binary blobs being distributed by vendors who don't want to release the source for their drivers and what-not... well more than I already do.

    Perhaps I am misunderstanding something and that 32 bit calls are still an inherent part of 64 bit Linu

    • by 0123456 (636235)

      Okay, I get that when system calls are made to 32 bit whatever, bad things could happen. But why would there be anything 32 bit there at all? Shouldn't everything that is running on a server be compiled for 64 bit?

      Flash. Ubuntu handles 32-bit Flash integration automatically with 64-bit Firefox, but on some other distros it's easier just to install 32-bit Firefox instead.

      • by koreaman (835838)

        If you're using your Linux server to browse Flash apps on the web, you might be doing it wrong...

        • by 0123456 (636235)

          If you're using your Linux server to browse Flash apps on the web, you might be doing it wrong...

          Yeah, I missed the 'server' part :).

    • Flash and Java are almost necessities on many servers. Sun Java and Adobe Flash have lacked 64 bit support, so 32 bit versions were mandatory. Or, nearly mandatory. There are options to Sun and Adobe, but performance isn't exactly the same. (Not saying better or worse, just different, which can be a problem in and of itself) When Adobe and Oracle both get around to releasing a consumer grade, final version of these ubiquitous applications, then Linux and Windows will both probably drop 32 bit compatibi
      • by iammani (1392285)

        Java may be, but flash?

        • by bsDaemon (87307)

          When I worked at a web hosting company, we once had a customer call in to complain that javascript and flash weren't running on our servers. Of course, they aren't supposed to....

    • Re: (Score:3, Informative)

      by dbIII (701233)
      I've got some very expensive commercial software on my nodes which is produced by utter idiots that have put 32bit binaries in directories called "linux64". They've been migrating their stuff from 32bit to 64bit since 2003 so they'll get there eventually. Until then it's a mixed system with a lot of undocumented messing about to install their software.
      Everything else on there was compiled for 64 bit.
      • by hitmark (640295)

        makes one wonder what the money gets used for.

        • Marketing and Sales.

          • Re: (Score:3, Interesting)

            by mr_mischief (456295)

            Around 15% to 25% of revenues going to customer acquisition and retention (marketing, sales calls, rebates, incentives, whatever) is a pretty common budgetary decision in US businesses. So yeah, after payroll, facilities, and other operating costs marketing and sales are a major expense. The most common advice I get as a small-business owner both online and in person from other business owners is 20%.

            I've heard as low as 10%, but that's still a big chunk of the budget. I've also heard of people spending as

    • by melikamp (631205) on Sunday September 19, 2010 @01:13AM (#33624908) Homepage Journal

      The vulnerability is affecting kernels compiled with 32-bit compatibility support. Enabling this option seems to be the default, even on x64 systems that do not have 32-bit libraries and cannot execute 32-bit binaries. You can say

      zcat /proc/config.gz | grep CONFIG_IA32_EMULATION

      to see if you have it on. More info [linuxquestions.org], and the origina [sota.gen.nz] hack [sota.gen.nz].

  • Bit late to be news (Score:5, Informative)

    by 0123456 (636235) on Saturday September 18, 2010 @09:50PM (#33623648)

    Ubuntu, at least, has already released the patch as a kernel upgrade; it was fixed early in the week so I presume most other distros have too.

    • Re: (Score:3, Informative)

      by melikamp (631205)

      Slackware forum [linuxquestions.org] has a link to the white hat's page [sota.gen.nz]. Here [sota.gen.nz] you can get a very neat proggy that will root you in less than 200 if you are still unpatched.

    • Re: (Score:3, Informative)

      by jroysdon (201893)

      RHEL was never affected. Red Hat BugID 630551 [redhat.com] states:
      "This issue did not affect the version of Linux kernel as shipped with Red Hat
      Enterprise Linux 3, 4, and 5 as it did not include upstream commit 7034632d
      that introduced the problem. It did not affect Red Hat Enterprise MRG as the /dev/sequencer device file is restricted to root access only."

      Further, Red Hat states for CVE-2010-3080 [redhat.com] that the commit upstream that brought the bug back was never allowed into Red Hat kernels:
      "This issue did not affect the ver

  • code comments? (Score:5, Insightful)

    by Cyko_01 (1092499) on Saturday September 18, 2010 @10:33PM (#33623842) Homepage

    Hawkes says the vulnerability was discovered and remedied back in 2007, but at some point in 2008 kernel developers apparently removed the patch, reintroducing the vulnerability

    and this, my friends, is why we add comments to our code

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      > and this, my friends, is why we add comments to our code

      It's also a good argument for regression testing.

      • by JohnFluxx (413620)

        The old exploit didn't work as-is, but required slight changes. So I don't know if regression testing would have caught it here.

        But of course, the kernel does need more unit tests.

  • is Ric Romero writing about security now?

  • by Laebshade (643478) <laebshade@gmail.com> on Sunday September 19, 2010 @12:11AM (#33624456)

    News like this makes me smile that I decided to use Gentoo Hardened 64-bit nomultilib whenever I built servers. Makes it harder if the software needed to run is only available as 32-bit binaries, but I haven't run into any yet that I've needed.

    Since it has no 32-bit emulation layer, this is probably one of the few 64-bit linux not affected (without a patch).

  • "The older exploit apparently only needed slight modifications to work with the new hole." That's what she said.

There's got to be more to life than compile-and-go.

Working...