Slashdot Mirror


Root Privileges Through Linux Kernel Bug

Lars T. writes "The H has a story about a Linux kernel bug that allows root level access. 'According to a report written by Rafal Wojtczuk (PDF), a conceptual problem in the memory management area of Linux allows local attackers to execute code at root level. The Linux issue is caused by potential overlaps between the memory areas of the stack and shared memory segments.' SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. The bug is not related to the X Server bug found by Brad Spengler." As the linked article notes: "SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability."

131 comments

  1. Unrelated? The PDFs are the same! by Anonymous Coward · · Score: 4, Informative

    How can the two bugs be unrelated? both articles have the exact same link to the exact same PDF! (Hint: the pdf's filename is xorg-large-memory-attacks.pdf on both).

    1. Re:Unrelated? The PDFs are the same! by NeverVotedBush · · Score: 4, Insightful

      I think what it is is that the Xorg server is an easy attack vector for the Linux kernel memory management issue.

      The memory management issue is the thing that enables using a flaw in the X server to escalate privilege. If you fix the X server to not allow that kind of manipulation, you still have the kernel memory management issue that could be used by some other application to escalate privilege.

      I think that fixing the X server - one mitigation is to disable the MIT-SHM extension as discussed in the pdf - really reduces the exposure but since the real problem is in the kernel, it doesn't completely remove the threat.

      At least that is how I understand it...

    2. Re:Unrelated? The PDFs are the same! by Tumbleweed · · Score: 2, Funny

      How can the two bugs be unrelated? both articles have the exact same link to the exact same PDF! (Hint: the pdf's filename is xorg-large-memory-attacks.pdf on both).

      The identical links are caused by another bug called PEBKAC.

    3. Re:Unrelated? The PDFs are the same! by lortho · · Score: 5, Informative

      It's because both articles are actually about the Wojtczuk report, and they both mis-quote Joanna Rutkowska as stating the bug is related to Spengler's X-Server flaw. She clarifies in an update to H-Online's version of the article that she was misunderstood and that they are actually unrelated.

    4. Re:Unrelated? The PDFs are the same! by Anonymous Coward · · Score: 0, Troll
      Not really.

      Microsoft marketing's pissed that Slashdot is discussing 40 currently exploitable Windows vulnerabilities, so they've paid the Slashdot shills to dupe the Linux vuln at least 40 times.

      And, you might note they're STILL discussing Linux in the Windows thread....

    5. Re:Unrelated? The PDFs are the same! by Anonymous Coward · · Score: 0

      "In an email to The H, Joanna Rutowska clarifies that Spengler's exploit targets "some unrelated vulnerability" and her reference to it was in relation to guesses made by Spengler noted in the source code comments."

    6. Re:Unrelated? The PDFs are the same! by Peach+Rings · · Score: 4, Informative

      Also if you read linus's patch notes they're the exact same problem.

    7. Re:Unrelated? The PDFs are the same! by bjourne · · Score: 2, Informative

      I think that fixing the X server - one mitigation is to disable the MIT-SHM extension as discussed in the pdf - really reduces the exposure but since the real problem is in the kernel, it doesn't completely remove the threat.

      The shm extension is integral to all modern xorg servers. You *may* be able to run xorg without shm, but many programs will refuse to work and performance will drop to a few percent of what it is with shm enabled. It's the transport the X server uses for communication with its client. With shm (shared memory) disabled, it has to serialize all objects and send them over a socket which of course is dog slow.

    8. Re:Unrelated? The PDFs are the same! by Anonymous Coward · · Score: 0

      Whatever happened to the no-root-x project?

    9. Re:Unrelated? The PDFs are the same! by mzs · · Score: 1

      Hmm... It's really the pixmaps that are way faster over MIT-SHM. If you are local than the unix domain socket is not all that much slower, there is an extra copy involved. With the pixmap you can just modify the image directly. Though there was a long time where this was not universal, and when you expected it to work sometimes it did not since the 2D acceleration in the driver broke it since the pixmap was really in framebuffer memory.

      But for a long time people have been doing XShmQueryVersion() and only using the extension if present. The reason for that is to have it work right when server and client are remote. The only software I have seen that relies on XShm also uses OpenGL anyway.

    10. Re:Unrelated? The PDFs are the same! by mzs · · Score: 1

      Does this really address the problem, won't using something like "int foo, bar[0x10000], baz;" in a function be able grow your stack around the SIGBUS check?

  2. Re:Linux! "It just works!" by Anonymous Coward · · Score: 1, Interesting

    Indeed, 5 years old and no exploit. Patched several years ago by the distros. The question is why didn't it get back into the kernel tree.

  3. Re:Long live to SUSE??? by valeo.de · · Score: 2, Informative

    No, just that this particular bug has been patched in SUSE for six years, while mainline has only just gotten the fix.

    --
    cat: /home/valeo/.sig: No such file or directory
  4. Nothing to see here.... by interfecio · · Score: 3, Informative

    From the RedHat bug report: Eugene Teo (Security Response) 2010-08-12 21:44:06 EDT Linus has committed a fix for this issue: http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893

    1. Re:Nothing to see here.... by JohnFluxx · · Score: 5, Insightful

      I don't agree that it's "nothing to see here" - something has gone wrong if it took 6 years for this to happen.

    2. Re:Nothing to see here.... by _Sprocket_ · · Score: 1

      Isn't it something to see / know about until one gets that fix out to the kernel on our live system(s)? We expect a speedy fix. Now begins the race to get the fix live.

    3. Re:Nothing to see here.... by Americano · · Score: 4, Insightful

      Nothing to see here? Will you say the same thing when Microsoft waits 6 years to apply a fix to WinXP? :)

      Yes, these things are less likely to happen with Linux. That doesn't mean Linux kernel processes are above reproach, and can't be made more responsive & accountable in cases like this where somebody obviously dropped the ball on merging a patch somewhere. I hope they spend a little time reviewing how this got missed, to make sure it's not a flaw in their process that could allow it to happen again.

    4. Re:Nothing to see here.... by gmuslera · · Score: 1

      Still is something to see there, at least for a few days till maintained distributions push that patch to their kernels and pushes them to the people that keep doing security updates. And for old, running unmaintained distributions servers, could be a bit more complicated. Still, this is a local vulnerability, and not exactly trivial to exploit.

    5. Re:Nothing to see here.... by Beelzebud · · Score: 3, Funny

      "Nothing to see here....." says Lt. Frank Drebin, as the fireworks factory behind him burns to the ground.

    6. Re:Nothing to see here.... by Anonymous Coward · · Score: 2, Funny

      Here at Linux Vintners, we will commit no bug fix before its time.

      This properly aged bug fix boasts an intense, highly indented C syntax and fragrant blackberry, vanilla, and dark chocolate comment style with just a hint of peppercorns. Richly textured and firmly structured, its lavish blackberry, ripe black plum, dark cherry and spice flavors are enlivened by crisp lint-warning-free compilations. Given its superb balance of fruit, oak, acid and tannin, this sumptuous contextual patch aged beautifully for 6 years, and is now ready to be enjoyed with 2.6 kernels on every platform.

    7. Re:Nothing to see here.... by petermgreen · · Score: 3, Insightful

      Agreed it would be good to know where the breakdown in communication happened. Did it get ignored because the submitter didn't realise it was a security issue and report it as such? Did someone just miss an email somewhere? (and if so why wasn't there a system in place to keep track of current security bugs and make it bloody obvious which ones still needed fixing along with someone responsible for looking at that list and fixing them). Was the breakdown on the SUSE side or the upstream side?

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    8. Re:Nothing to see here.... by Target+Practice · · Score: 1

      And I raise a mug of coffee to all my fellow sysadmins this evening. There goes my damned server uptime, and here comes my damned conscious uptime.

      Sleep... she is for the weak!

      --
      There's a 68.71% chance you're right.
    9. Re:Nothing to see here.... by Warll · · Score: 4, Funny

      He's right, real men don't look at explosions.

    10. Re:Nothing to see here.... by h4rr4r · · Score: 0, Troll

      Why is X on a server?

      Sounds like something a windows user/sysadmin would do.

    11. Re:Nothing to see here.... by _Sprocket_ · · Score: 1, Troll

      Because if you don't have a flashy screensaver going, all the black will cause the damn Windows sysadmin to think that port of the KVM is unused and he can swipe it for another box.

    12. Re:Nothing to see here.... by valeo.de · · Score: 0, Redundant

      Apparently the patch that Andrea Arcangeli submitted back in 2004 was deemed too ugly for inclusion. I've not been able to find an authoritative source on this though, so by all means take this with heaps of salt.

      --
      cat: /home/valeo/.sig: No such file or directory
    13. Re:Nothing to see here.... by jittles · · Score: 4, Interesting

      My guess would be an oversight at kernel.org. I submitted a kernel patch to the USB HID driver back in the days of 2.6.10 and 2.6.13. The driver was incorrectly suspending its state (I can't remember what it was doing off the top of my head) while it held onto a spinlock. The result was 100% CPU utilization when you called certain ioctls made available by the driver. The patch didn't make it in until 2.6.17 if I recall correctly, and not until someone with a name submitted a patch for it.

    14. Re:Nothing to see here.... by Target+Practice · · Score: 2, Informative

      It's not, but the Linux kernel is... and that's where the vulnerability is...

      --
      There's a 68.71% chance you're right.
    15. Re:Nothing to see here.... by LingNoi · · Score: 1

      See my post further down..

      http://linux.slashdot.org/comments.pl?sid=1760032&cid=33310162

      It's already available for download. I gave ubuntu as an example however I'm pretty sure other distributions have also already provided the update too.

    16. Re:Nothing to see here.... by LingNoi · · Score: 2, Informative

      Race?

      The most popular distros already patched it days ago and others are currently in testing.

      Redhat patched it 2 days ago.
      Ubuntu patched it 2 days ago.
      Fedora is currently testing the patches. Not sure if it's already live.
      Debian Lenny has patched it.

    17. Re:Nothing to see here.... by PReDiToR · · Score: 1

      What on earth would you need a KVM for on a Linux server?

      SSH on a non-standard iptables limited port should be the only way into a Linux server, shouldn't it?

      --

      Do not meddle in the affairs of geeks for they are subtle and quick to anger
    18. Re:Nothing to see here.... by dave562 · · Score: 1

      That's all great, until the switch fails. Let me know when SSH overcomes that whole lack of network connectivity scenario.

    19. Re:Nothing to see here.... by _Sprocket_ · · Score: 2, Funny

      That's actually an inside joke. I did have a box that I had originally racked and set up on the rack KVM. Almost 2 years later, I was intending to walk up to the box and boot it in to single user mode to find out that someone had decided we never used the KVM port and had set it up for some other system. When I asked around, the best guess was that I had lost my spot on the KVM at least a year ago. I wondered aloud whether I needed to run a screensaver banner that claimed ownership of the KVM port to keep it.

      And yes - the vast majority of interaction with that box was via SSH (although I had no reason to put it on a non-standard port).

    20. Re:Nothing to see here.... by _Sprocket_ · · Score: 1

      Race?

      The most popular distros already patched it days ago and others are currently in testing.

      Yes, race. All that is part of it. But that doesn't put the kernal live on any given system. I have to take that step. And, depending on your environment, that may require a bunch of other operational steps.

      I'm not making a comment on the difficulty of doing any of this (it tends to be quick and painless in most situations). I'm noting that this is, in fact, news. There IS something to see here. People who are in the position to update a kernal should know about this and know to push it (if they haven't already).

    21. Re:Nothing to see here.... by Bert64 · · Score: 1

      Apparently you need an X server to install and run some parts of Oracle...

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    22. Re:Nothing to see here.... by Bert64 · · Score: 1

      Well, i usually use serial consoles instead of a KVM...

      A basic KVM is cheap, but IP based ones are pricey.. Serial consoles are cheap and you can still access them without having to go and stand in the server room.
      Plus an IP based KVM uses a lot of bandwidth to transfer screendumps over the network, making it rather useless on a slow link.... Serial is much better in this regard.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    23. Re:Nothing to see here.... by LinuxIsGarbage · · Score: 2, Interesting

      How great does the serial console work if the system won't boot?

    24. Re:Nothing to see here.... by ThatsNotPudding · · Score: 1

      And Gentoo is issuing a patch to reconfigure the electrons that will be used by the emerge process.

    25. Re:Nothing to see here.... by Anonymous Coward · · Score: 0

      ... they walk away from them in slow motion.

    26. Re:Nothing to see here.... by Anonymous Coward · · Score: 0

      if the switch fail, you repair the switch. why would a sysadm want to connect to a server to fix a switch problem?

      duh!

    27. Re:Nothing to see here.... by dave562 · · Score: 1

      Lets see... there is data on the server that needs to be accessed NOW, not between now and the time switch gets fixed.

    28. Re:Nothing to see here.... by Anonymous Coward · · Score: 0

      wow, you really fail at managing task dependencies. that sounded as if coming straight out off one of those pointy haired abusive dilbrtesqe bosses.

    29. Re:Nothing to see here.... by Americano · · Score: 0, Troll

      You see, in the real world, not everything is as pretty as your MS project plan.

      Somebody using the term "managing task dependencies," comparing a sysadmin to a Dilbert-style PHB? That's fucking rich.

    30. Re:Nothing to see here.... by sjames · · Score: 1

      It's needed very occasionally when you want to diagnose why it has lost network connectivity.

    31. Re:Nothing to see here.... by g1zmo · · Score: 1

      SSH on a non-standard iptables limited port should be the only way into a Linux server, shouldn't it?

      On cheap commodity hardware, maybe. On real server equipment you have an out-of-band management controller.

      --
      I have found there are just two ways to go.
      It all comes down to livin' fast or dyin' slow.
      -REK, Jr.
    32. Re:Nothing to see here.... by dave562 · · Score: 1

      Here you go. Here is a real world, just happened to me example of why you need physical access to a server. We have redundant load balancers and redundant switches for our front end web servers. The load balancers glitched and for whatever reason stopped forwarding traffic to one of the virtual IPs. It wasn't enough of a glitch for them to fail over or to throw an alert. The other two VIPs on the load balancers were still working fine. It took me fourty-five minutes to coordinate with the network team, diagnosis the issue, and re-create a NAT rule to route around the borked load balancer.

      If any time during that 45 minutes, some PHB had come to me and told me that he needed data off of that server RIGHT NOW, I would have needed physical access to the console. SSH wouldn't have done jack shit for me. I would have had to physically access the box, put a stupid USB stick into the physical piece of hardware and transfered whatever data the imaginary PHB needed.

      Anyone who gets on someone else's case for "failing at managing task dependencies" hasn't worked in the real world long enough. You can have redundancies up the wazoo and things will still go sideways from time to time. If a person is so ignorant to believe that the only access they will ever need to their Linux box is an SSH connection, then that person deserves the down time they will be facing sooner or later.

    33. Re:Nothing to see here.... by Anonymous Coward · · Score: 0

      if any phb needs some data *right now*, he's not worth of managing anything.

      every time an urgency arises, somebody failed planning - why are you looking for critical data less than an hour before you need it? any critical piece of information should be on your hands well in advance (and properly replicated)

      also, by the time you're in the server room fetching the data, you could have the router/switch whatever replaced and be done with it

      but yeah, I'm sorry if your *real world* sucks. there are better working places out there.

  5. Wait... what? by Dumnezeu · · Score: 0, Troll

    I don't understand TFH / TFS / TFA. Are we talking about local privilege escalation by overwriting the memory space owned by processes running as root?

    --
    Yes, it's sarcasm. Deal with it!
    1. Re:Wait... what? by Anonymous Coward · · Score: 0

      Yes.

    2. Re:Wait... what? by Short+Circuit · · Score: 2, Informative

      If I read the git patch correctly, if said root process has a memory-mapped page coincident with a non-root process, and the non-root process can write to said memory mapped region (via having it memory mapped into their own process), then said non-root process can affect the behavior of the root process.

      What was broken, and appears to have been corrected, is that an application's *stack* could grow into a memory-mapped page and corrupt the data in the root process while it's at it. (The stack is a piece of memory that hold data about the functions currently executing in a particular thread in your program.)

      (enter educated guess section; I spend most of my time coding userland apps on Windows, not Linux.)

      The case where this seems most possible to exploit is the loading of shared libraries. I don't know if the same mmap mechanism is used by the kernel, though. While it's entirely probable that writing to that region is protected, so long as the application is doing so under its own memory privilege level, it's possible that there's a syscall into the kernel that expands a thread's stack when the allocated memory for that stack is nearly exhausted. The syscall's operations run with kernel privileges, and it looks like the stack page allocator wasn't sufficiently checking the properties of the userland address it was allocating stack into.

      (end educated guess section; I'm probably wrong, anyway.)

    3. Re:Wait... what? by mandelbr0t · · Score: 4, Informative

      Actually, no, this is a simple Stack Buffer Overflow. Basically, by causing a running privileged process (e.g. X Server) to make a recursive call, the stack will grow into memory space owned by the unprivileged user. Now, all the unprivileged user has to do is put some code somewhere (perhaps by exploiting another buffer overflow) and rewrite the return address, which lives in its memory page.

      The fix adds a guard page between the shared memory region and the system stack to protect against the stack growing into memory where it is no longer protected. At any rate, ProPolice would have prevented this mistake from being exploitable.

      --
      "Please describe the scientific nature of the 'whammy'" - Agent Scully
    4. Re:Wait... what? by Short+Circuit · · Score: 1

      Wait...they didn't already have a guard page? I kinda assumed that was already there. Ow.

      *marks self down as "needs improvement" in patch reading comprehension skills*

  6. Re:Linux! "It just works!" by nizo · · Score: 1, Troll

    I wonder how many bugs like this are lurking in closed source products, just waiting to be discovered and exploited?

  7. Re:Linux! "It just works!" by nomadic · · Score: 5, Funny

    Indeed, 5 years old and no exploit. Patched several years ago by the distros. The question is why didn't it get back into the kernel tree.

    Why not ask the kernel developers? Nah, I'm not just joking, don't ask those nutjobs anything, they'll just freak out and start yelling at you.

  8. Re:Linux! "It just works!" by Anonymous Coward · · Score: 0

    And the relevance of your post other than a weak attempt at deflection is what?

  9. Re:Linux! "It just works!" by Anonymous Coward · · Score: 0

    And that's the point, in the case of closed source software you can only wonder. :-)

  10. Re:Long live to SUSE??? by Inner_Child · · Score: 1, Troll

    Then why wasn't the patch submitted to mainline six years ago? Or if it was, why did it take so long to get accepted?

    --
    Today is red jello day - all workers must eat all of their red jello. Failure to comply will result in five demerits.
  11. Re:Ummmmm, a local exploit. by maxwell+demon · · Score: 2, Insightful

    No, normally access to the machine at user level should not imply access to the machine at root level.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  12. Re: Ask the Kernel Overlords by xiando · · Score: 4, Interesting

    Why not ask the kernel developers? Nah, I'm not just joking, don't ask those nutjobs anything, they'll just freak out and start yelling at you.

    I've seen many similar statements, so there may be some truth to this, but my experience is that they give you a short-as-possible only-most-relevant question such as "Can you bisect?" or reply like "Patch rejected: missing signoff". It appears their time is very valuable or they have to pay $5 pr. typed letter.

  13. Re:Ummmmm, a local exploit. by NeverVotedBush · · Score: 1

    I think ssh counts as access...

  14. Re:Ummmmm, a local exploit. by Anonymous Coward · · Score: 0

    I'm logged into a server with >100 other users at the moment.

    I don't have root access and in all likelihood never will (unless I become an admin, which involves passing 2 tests and getting elected).

    The possibility of me, or any of the other 100 non-admins, getting root access to the machine is a very big deal.

  15. Re:Ummmmm, a local exploit. by Beelzebud · · Score: 2, Interesting

    If it's a non-story then why did Linus patch it today? Apparently he didn't agree with your flippant way of looking at OS security.

  16. Re:Linux! "It just works!" by MobileTatsu-NJG · · Score: 3, Insightful

    I wonder how many bugs like this are lurking in closed source products, just waiting to be discovered and exploited?

    I wonder how many bugs like this are lurking in open source projects, just waiting to be discovered and used against people that assume that the software they use is secure because they read Slashdot comments.

    --

    "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  17. Re:ZOMG!!! by Dunbal · · Score: 3, Insightful

    What part of "local attackers" do you fail to understand?

    --
    Seven puppies were harmed during the making of this post.
  18. Re:Long live to SUSE??? by alanebro · · Score: 0, Redundant

    You didn't even read the summary, let alone the article. Good work.

    From the article: 'As the linked article notes: "SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability."'

  19. Tuesday by dandart · · Score: 2, Funny

    At least we don't have to wait for four Tuesdays' time for the fix...

    You're holding it wrong.

    1. Re:Tuesday by Gadget_Guy · · Score: 4, Funny

      At least we don't have to wait for four Tuesdays' time for the fix...

      No, we had to wait over 300 Tuesdays for the fix to the kernal. That's 75 times better!

    2. Re:Tuesday by Anonymous Coward · · Score: 0

      Ohh come on. Microsoft doesn't fix it and then once they do you still have to wait for patch Tuesday! Give me a break. This just got overlooked somehow. Once it was realized we had patches in days not weeks or months. There isn't a patch Tuesday on GNU/Linux land.

    3. Re:Tuesday by Anonymous Coward · · Score: 0

      At least we don't have to wait for four Tuesdays' time for the fix...

      No, we had to wait over 300 Tuesdays for the fix to the kernal. That's 75 times better!

      Kern*a*l? I was about to cheer that there are survivors from the Commodore 64 era, but your UserID is too high for that...

  20. Re:Linux! "It just works!" by Nerdfest · · Score: 2

    Sometimes people make mistakes.

  21. Re:ZOMG!!! by GameboyRMH · · Score: 4, Funny

    Cut the guy a break, he's a Windows fanboy. He probably thinks a local user is just anyone in the same geographic region.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  22. Re:Long live to SUSE??? by alanebro · · Score: 5, Informative

    Cut my post too short.

    "SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel"

  23. The Beauty of Open by amiga3D · · Score: 1, Troll

    Amazing that SUSE fixed this in it's distro. In the proprietary world they'd still be waiting for the OS maker to fix it. SUSE just fixed it themselves. Many windows bugs could have been fixed but yet remained waiting for years until MS got around to it.

  24. Re:ZOMG!!! by cbhacking · · Score: 2, Insightful

    He's a troll, but that doesn't mean that there isn't a grain of truth to what he implies. Most Windows exploits are also technically local attacks, as are Trojans (by definition). Somebody thinking that they're safe (because the software runs with limited permissions) would be in for a nasty surprise if an attacker exploited this.

    --
    There's no place I could be, since I've found Serenity...
  25. Re:Linux! "It just works!" by Hatta · · Score: 4, Insightful

    Indeed, 5 years old and no exploit.

    How do you know?

    --
    Give me Classic Slashdot or give me death!
  26. Re: Ask the Kernel Overlords by Zero__Kelvin · · Score: 4, Informative

    "I've seen many similar statements, so there may be some truth to this, but my experience is that they give you a short-as-possible only-most-relevant question such as "Can you bisect?" or reply like "Patch rejected: missing signoff". It appears their time is very valuable or they have to pay $5 pr. typed letter"

    Behold the phenomenal power off Open Source! The time of each and every kernel developer is in fact a highly valuable commodity, yet I get the benefit of the fruits of their labor without shelling out a sixpence! And the best part? This was fixed last week.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  27. Re:0h n03z! by gmagill · · Score: 1

    a redundant first post...?

  28. Already fixed in Ubuntu by LingNoi · · Score: 4, Informative

    So I read the PDF...

    The Linux kernel versions that include the commit 320b2b8de12698082609ebbc1a17165727f4c893 from Linus tree are fixed.

    which is the patch.. "Patch "mm: keep a guard page below a grow-down stack segment" has been added to the 2.6.32-stable tree"

    and meanwhile my ubuntu update managaer pops up and shows an update for the kernel and gives the following link to the changelog...
    http://launchpad.net/ubuntu/+source/linux/2.6.32-24.41/+changelog

    * mm: keep a guard page below a grow-down stack segment - CVE-2010-2240

    Nice to see people are on the ball with security updates, even if it shouldn't have been happened in the first place.

  29. Re:Linux! "It just works!" by LingNoi · · Score: 1

    Bugs are apart of software as a whole. Every program open or closed is vulnerable to some kind of bug. The difference being however that with linux bugs I tend to hear about them after I already downloaded the fix.

  30. Re:Wow! Linux is really Secure. by jours · · Score: 4, Insightful

    Look at this graph: http://linuxinsecurity.blogspot.com/

    Please do. Notice how the graphs show Windows with 10-12% of the issues unpatched?

    That's the problem. Well that and the missing graph showing "time to patch"...

    --
    This sig intentionally left blank.
  31. Re:Long live to SUSE??? by Anonymous Coward · · Score: 0

    It was probably the "Linus doesn't scale" issue.

    It used to be that everyone just emailed patches to Linus, and if he wasn't too drunk he would sometimes patch them into the kernel tree. This started becoming seriously unworkable in the 2.4-2.5 time period, which lead a much more systematic approach of version control systems, shorter release cycles, lieutenants and sub-maintainers and so on.

  32. Re: Ask the Kernel Overlords by smash · · Score: 3, Interesting

    So, only 6 years late then? SuSE just went way up in my book.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  33. Re:0h n03z! by Spy+der+Mann · · Score: 2, Funny

    a redundant first post...?

    Yes, there was a redundant x in "h4xx0r5".

  34. Compare to Apple... by Myria · · Score: 2, Interesting

    Compare this to Apple, which still hasn't fixed my Darwin kernel ring 0 exploit, which I reported in June.

    It's x86-only, so no, it can't be used for the second step of an iPhone jailbreak. =(

    --
    "Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
    1. Re:Compare to Apple... by Americano · · Score: 1

      By my calculations, this means they've taken 2.5 months, which means they're about 5 years, 9.5 months ahead of schedule if they follow the 6 year benchmark set by the Linux kernel.

      What's the problem? They've got plenty of time!

  35. you didn't do it right by Chirs · · Score: 4, Informative

    If you really want to get a fix in, the correct procedure is to keep pestering the maintainer for that area until they accept your patch. If you can't get them to accept it, you go up the chain.

    Yes, in an ideal world all maintainers would be perfectly organized. In the real world things get lost, they get distracted, other issues pop up, and the patch doesn' t make it in.

    If you care about it...make some noise.

    1. Re:you didn't do it right by Kjella · · Score: 2, Insightful

      But the problem is that often if you know about it, it's not really a big issue to you. If I know about an ugly pothole in the road, I can with little effort drive past it. So why then should I spend my valuable time pestering the road maintainers about it? Granted, maybe not in this specific case as you can't avoid the security hole but bugs in general you can often avoid the condition triggering the bug.

      The first time you tell them, then maybe the only reason it's not fixed is because nobody told them about it. It's only other people who, having run into the pothole and wrecked their car and learning that the maintainers were in fact notified about it that get pissed. Like in this case, SUSE has been fixed for a long time so why should SUSE maintainers work their butts off getting it upstream?

      At times, upstream seem to think it's their god given right that downstream should feed them with everything they do. They don't, the only reason they do is if the benefit of getting it in the upstream tree outweighs the cost of doing it. If you need to pester upstream then that balance may tip in the favor of "Whatever, we'll just keep this in our own branch. Have a nice day." It's a loss for the community but you can't expect everyone to constantly work for the "greater good" and not their own itches.

      --
      Live today, because you never know what tomorrow brings
    2. Re:you didn't do it right by Anonymous Coward · · Score: 1, Interesting

      "...the correct procedure is to keep pestering the maintainer..." wow, THAT's a screwed up procedure. If I go through the effort of identifying a flaw and submitting a patch and the maintainer doesn't acknowledge my existence, the hell I'm going to keep pestering him...

      I mean THAT's the reality of it, it isn't that the maintainer just misplaced the e-mail. E-mails from Linus don't get accidentally misplaced. So why should e-mails reporting and fixing vulns get misplaced? It's BS and it's a little elitist club, and that needs to be fixed, rather than the submitter needing to dedicate his/her life to getting listened to by the members of the elitist club.

  36. Re:Linux! "It just works!" by Anonymous Coward · · Score: 0

    Yes, and with OSS we know exactly how many unpatched and undiscovered bugs there are!

    Oh, wait..

  37. Obligatory... by Pete+Venkman · · Score: 4, Funny

    This won't be a problem for me since I don't run Linux.

    Now the shoe's on the other foot!

  38. Re: Ask the Kernel Overlords by buchanmilne · · Score: 0, Flamebait

    So, only 6 years late then? SuSE just went way up in my book.

    SuSE just went way down in my book, to join the "we-don't-upstream" vendors such as Canonical.

    Really, there may have been an excuse for not upstreaming this during the linus-doesn't-scale period, but other distros have explicit "patch-review-in-order-to-upstream" initiatives, this one should have been caught by SuSE some time in the last 6 years, and reviewed by their kernel maintainers, and re-submitted.

  39. Re: Ask the Kernel Overlords by Anonymous Coward · · Score: 0

    So SuSE managed to patch every new kernel they incorporated in their system to include their patch for 6 years and didn't bother to tell it upstream (again)? It should have rung a bell every time they had to reapply their patch.

  40. Re:Wow! Linux is really Secure. by rolfc · · Score: 2, Informative

    Yes, something is seriously wrong with this comparison. You compare a clean and unused operatingsystem with a fullfledged Linuxdistribution with a lot of applications.

    Of course the Linuxdistribution will have more bugs, but you dont have to install all the software that comes with it. On the other hand, to be able to use the Windows server to something useful, you have to install more Microsoft and/or thirdparty software. It isnt even a webserver without installing more software in Secunias statistics. IIS has its own category.

    Dont compare apples and pears, you will only fool yourself.

  41. A fix that was overlooked by Artem+S.+Tashkinov · · Score: 1

    Suse developers suggested a fix for this vulnerability six years ago http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7904.html however for reasons unknown it wasn't noticed or merged.

  42. Re:Linux! "It just works!" by 1s44c · · Score: 1

    Indeed, 5 years old and no exploit.

    You can't be sure of that.

  43. Re:Wow! Linux is really Secure. by Bert64 · · Score: 1

    Also that full fledged linux distro has a single update mechanism for all of the applications... If you install equivalent apps on a windows system chances are they will need their own separate update mechanisms, or not have an update system at all, which massively increases the chance of unpatched apps being present.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  44. Re:The Beauty of Open by Anonymous Coward · · Score: 0

    Mmmh.. isn't Suse an OS maker ?
    I don't care if they get the kernel from somewhere else, they are selling me an OS.

  45. Old news ;) by Lavene · · Score: 1

    It's funny to see the windows people taking such satisfaction in Linux bugs and completely disregard the time it takes from disclosure to a fix is available. Usually I've already installed the fixed version before I read about it on slashdot. It's just a matter of subscribing to my distro's security announcement mailinglist and upgrade if I run the affected software.
    So in most cases, when i read about bad bugs in Linux it's 'old news'.

    (Blatantly ignoring the six years it took to actually get the fix into the kernel this time)

  46. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  47. Re: Ask the Kernel Overlords by Provocateur · · Score: 1

    You're lucky to get a "Can you bisect?"

    All I got was a "Does it blend?" and a derisive snort.

    --
    WARNING: Smartphones have side effects--most of them undocumented.
  48. Re:ZOMG!!! by Anonymous Coward · · Score: 0

    Most Windows exploits are also technically local attacks

    I dispute that. I always read the notes on the various updates that microsoft keeps pushing out to my windows machines, and quite a few of them talk about unauthenticated remote attackers being able to take over a system. Not all do, not even all the critical ones, but enough do.

  49. hi by juliawells20 · · Score: 0, Offtopic

    It's really quite interesting story. Nice ghoulish article very fitting for the season and impressively damn interesting. That was awesome! Probably one of the more interesting reads in awhile. http://www.worldpixelmile.com/

  50. this is news?? by Anonymous Coward · · Score: 0

    every kernel release after 2.6.35.2 dealt with this issue (which is why a few apps i use crash when they store too much data without setting a larger buffer). unless you're running oh...a version of linux dating that far backk and have never bothered to bet the updates, you have no issue. anybody using linux not only gets kernel updates, but new kernels (which is why i routinely purge the old files out of /boot and the modules out of /lib/modules...both to keep from having a ton of unwanted garbage to sort through as force of habit, and a throwback to when space was a premium...and of course edit the menu.lst file.

    what's next...rehashing problems with netscape 4?

  51. Re: Ask the Kernel Overlords by Anonymous Coward · · Score: 0

    Parent is not a troll. The fact that the patch has lingered in SuSE kernels for six years with no-one trying to re-submit it to upstream shows a serious flaw in their process. I wonder how many other SuSE-only patches they have?

  52. Re:Long live to SUSE??? by Anonymous Coward · · Score: 0

    Then why wasn't the patch submitted to mainline six years ago? Or if it was, why did it take so long to get accepted?

    "SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel"

    Soo ... we still don't know?

  53. Re:Linux! "It just works!" by Anonymous Coward · · Score: 0

    We don't know if there is an exploit or not, but given that no one has seen it, i tend to think that it doesn't exists. Especially because gaining root at a server is interesting, but not many servers have X11.

  54. Re:Linux! "It just works!" by nizo · · Score: 1

    I can audit the code myself, or pay someone else to audit it. Also thousands and possibly millions of people are already auditing it, for free! I can fix the bugs myself, or pay someone to fix them.

  55. Re:Linux! "It just works!" by MobileTatsu-NJG · · Score: 1

    The difference being however that with linux bugs I tend to hear about them after I already downloaded the fix.

    That's called a false sense of security.

    --

    "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  56. DEPLOY by Anonymous Coward · · Score: 0

    What about the race to all the people who need to update these kernels? ...someone somewhere there will be vulnerable boxes perhaps forgotten about, administered by monkeys or installed from CDROM.

    How long does it take for a vanilla Ubuntu to be owned connected directly to internet?

  57. Re:Linux! "It just works!" by LingNoi · · Score: 1

    No, it's simply a small piece of evidence that Linux gets fixed faster then windows does.

  58. Re:ZOMG!!! by cbhacking · · Score: 1

    A vulnerability in a graphics-decoding library used by IE is a local exploit, but it can be used by remote attacks who embed a malicious image in a website or email. That would meet exactly the description you gave, for the way that MS words their patch notes.

    Just because a vulnerability is local doesn't mean it can't be triggered remotely. It simply means that something needs to be done on the local machine - such as visiting a web page, reading an email, or running a supposedly safe command - for an exploit to occur. True remote vulnerabilities are also still found on rare occasion, but they've become extremely uncommon; external interfaces are subject to extremely heavy testing these days.

    --
    There's no place I could be, since I've found Serenity...
  59. Re:Linux! "It just works!" by MobileTatsu-NJG · · Score: 1

    Right. Like I said, a false sense of security. Think about the ramifications of what you're saying.

    --

    "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  60. Re: Ask the Kernel Overlords by smash · · Score: 1

    I view this as SuSE seeing the critical nature of the patch and including it irrespective of what Linus or the other kernel team guys think.

    That this was not included after submission was a fairly serious error.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  61. Re:ZOMG!!! by LingNoi · · Score: 0, Troll

    And just 4 days after you posted this, this happens.. Windows DLL Vulnerability Exploit In the Wild. The best part being, the linux security bug got fixed already, whereas the windows exploit is already out there on machines and makes 1000s of windows apps insecure.

    Just enough time for me to come back and gloat. Linux 1, Windows 0.

  62. Re:ZOMG!!! by Itninja · · Score: 1

    By that reasoning would not all attacks be local attacks? What would be an example of a "true" remote attack?

    --
    I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.