Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Bug Open Source Operating Systems Security Linux

5-Year-Old Linux Kernel Bug Fixed 127

rastos1 sends in a report about a significant bug fix for the Linux kernel (CVE-2014-0196). "'The memory-corruption vulnerability, which was introduced in version 2.6.31-rc3, released no later than 2009, allows unprivileged users to crash or execute malicious code on vulnerable systems, according to the notes accompanying proof-of-concept code available here. The flaw resides in the n_tty_write function controlling the Linux pseudo tty device. 'This is the first serious privilege escalation vulnerability since the perf_events issue (CVE-2013-2049) in April 2013 that is potentially reliably exploitable, is not architecture or configuration dependent, and affects a wide range of Linux kernels (since 2.6.31),' Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. 'A bug this serious only comes out once every couple years.' ... While the vulnerability can be exploited only by someone with an existing account, the requirement may not be hard to satisfy in hosting facilities that provide shared servers, Rosenberg said."
This discussion has been archived. No new comments can be posted.

5-Year-Old Linux Kernel Bug Fixed

Comments Filter:
  • by metrix007 ( 200091 ) on Tuesday May 13, 2014 @05:00PM (#46994093)

    Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.

    This is crap. A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

    When you don't assign the significant to security issues that they deserve, they go unpatched for 5 years.

    It's kind of a concern.

    • by metrix007 ( 200091 ) on Tuesday May 13, 2014 @05:04PM (#46994121)

      To expand on this, not only do they not assign security bugs the priority they deserve, they actively hide them.

      http://arstechnica.com/securit... [arstechnica.com]

      FWIW, I love Linux and used Slackware for almost a decade.

    • by Anonymous Coward on Tuesday May 13, 2014 @05:06PM (#46994145)

      Well it can't be patched before it was discovered but you seem to be implying this issue was known about 5 years ago.

      How long from when it was discovered did it take to be patched?

      • Re: (Score:1, Troll)

        by jcochran ( 309950 )

        The GIT entry for the bug was entered Dec 3, 2013. So that means at a minimum, the bug was known of and not fixed for 5 months. That's a bit excessive for 'A bug this serious only comes out once every couple years' kind of bug. I'll agree that 5 months is a lot shorter than 5 years, but it's still far too long.

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          Was it? Where? The git commit linked in the article is for 2014-05-03. Given the number of fixes and revisions this patch went through, one has to actually hunt it down in the MLs to know.

          So, can you please point us to the source of your information?

        • Re: (Score:1, Troll)

          by metrix007 ( 200091 )

          Given that the people in charge don't tend to disclose security vulnerabilities and actively hide them, it's difficult to say how long it was known for.

      • Bugs can be ancient. anyone remember that Windows VDM bug that affected every version of Windows based on NT? How is this bug different?

        Bugs have to be found, you can't expect every bug to just be easy to find. That's how things like Heartbleed, and the VDM bug don't get discovered for years. I'm sure there's probably bugs almost as old as Linux itself in the kernel, and i'm almost certain there's bugs in Windows affecting everything from 3.1 up.

        But yes, i'd be very suprised if this bug was reported 5 y
    • Re: (Score:2, Insightful)

      by waddgodd ( 34934 )

      Well, in a normal situation, I'd say yes, but Linux's response to all bugs is similar, patch it as soon as there's a good patch. Now if it were a certain company in Redmond that scales its response based on customer "value", yeah, security bugs had best get fast-tracked. I honestly prefer the "fix all bugs and don't embargo fixes" response that linux does to the "when we discover bugs (heartbleed), we'll let the Cool Kids in on it first and then release it weeks later to the average user" response that Go

      • Re: (Score:3, Interesting)

        by metrix007 ( 200091 )

        You should read up some more on the clash between security professionals and the Linux maintainers.

        Some bugs are more critical than others, and hiding them not to get negative attention or (rightfully) be pressured to fix them is pretty bad.

        • by waddgodd ( 34934 )

          Don't see where your flamebait actually changes anything. It certainly provides nothing new, because you can say "they're rude" all day, the question is is the bug in question fixed, and when. Yes, the chances are very good that a bug submitter is going to get a "patch or GTFO" response. In the overall scheme of things, I'd say that's as good as can be expected, given many other groups respond with legal threats.

          • Excuse me, but what flamebait? I did not insult you or your argument, instead I made a valid counter argument.

            Oh, and my point wasn't that the maintainers are rude. My point is that the security industry keeps insisting the the Linux team practice responsible disclosure, and they keep arguing there is no need or benefit.

          • Yes, the chances are very good that a bug submitter is going to get a "patch or GTFO" response.

            Not my experience. If you report a serious bug wirth enough supporting information it's quite likely someone else will propose a patch.

    • Linux and Greg K-H have both gone on record

      Who is "Linux"?

    • by naasking ( 94116 )

      A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

      I agree security vulnerabilities are worse than simple bugs. However DoS is not. Our entire network infrastructure is already vulnerable to DoS, so vulnerabilities of this sort are just par for the course really.

      • Might want to check the GIT report again. To quote: ... which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings. ...

        Notice that the bug permitted an easy denial of service attack. And with more effort a privilege elevation.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          There's no such thing as "GIT report" mentioned anywhere here, only GIT commits and they're too recent...

          Did you mean CVE? CVEs reservation dates don't correspond with bug discovery date - for example, CVE numbered one less than this one is not even created yet [mitre.org], but it lists the same "20131203" reservation date.

        • by naasking ( 94116 )

          I'm not referring to any specific DoS, just DoS as a general class aren't necessarily security vulnerabilities, ie. specific DoS vulnerabilities might also be security vulnerabilities, but being a DoS vulnerability does not automatically also make it a security vulnerability.

          • Any bug that allows a remote attacker to compromise a system, be it stealing data or denial of service, is a security vulnerability. All DoS vulnerabilities are security vulnerabilities by definition.

            • by naasking ( 94116 )

              You're missing the point: our network infrastructure is already DoS vulnerable. A remote DoS is just another drop in a full pool. To suggest that a DoS vulnerability "compromises" the remote system doesn't seem justified.

              • Fair enough, I think we're talking semantics here now. All I know is a lot of my clients do, and rightly so, consider DoS to be a security issue.

    • by wisnoskij ( 1206448 ) on Tuesday May 13, 2014 @06:09PM (#46994537) Homepage

      I completely disagree. The reason I use a OS is because its features work and it doe snot crash all the time, I could not care less if it were 1% more secure.

      • I gotta say (Score:2, Funny)

        by Anonymous Coward

        a "doe snot crash" sounds pretty bad to me. Just sayin'. Do you have deer hanging around your computer?

      • Stability and security are not mutually exclusive.

        Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.

        • Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.

          True, but most stability problems do not stem from malicious attacks.

    • by ilotgov ( 637717 )
      Who is Linux agian?
      • If you can't tell who was meant from the context, you should probably head on over to some other, simpler website. Perhaps Mac Rumors.

    • A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

      You are right, but it doesn't apply in this case. This was a privilege-escalation exploit, which means you already need an account on the computer to do anything.

      It's still a problem and I'm willing to bet there are more of these in the Linux kernel, just because they're so tough to clean out.

      • The examples I used in my post were just that, examples. They were not meant to be specific to this story, as I think the issue is greater than just this story.

      • by tlhIngan ( 30335 )

        This was a privilege-escalation exploit, which means you already need an account on the computer to do anything.

        Any account would do. Even say, "nobody".

        All you need is the ability to run an arbitrary binary, which a buggy CGI script is more than adequate. Basically, if you have a bit of shellcode, that's sufficient. Once you have that going, then you can easily exploit your way to more priviledges.

        That said, for the time being we now have a good way to root our Android phones.

        • That said, for the time being we now have a good way to root our Android phones.

          .......until you reboot. Unless you can get at the bootloader.

    • A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

      May be. But this particular bug does not allow remote anything. It requires a local malicious user. PFTFCVELITS (Please Follow The Fine CVE Link In The Summary)

    • by Threni ( 635302 )

      > This is crap. A bug that allows remote code execution or even a DoS is a much,
      > much bigger issues than fixing the user experience or minor stability issues.

      You're not a security professional. You should have to put that in your sig file. The linux kernel is used in many different situations, and clearly some security problems only pose a risk in some of those situations. IE. a lot of embedded systems will never be vulnerable to this particular issue.

      A bug is a bug. All bugs should be triaged an

      • A bug is a bug. All bugs should be triaged and then treated accordingly. You don't pretend a bug is more important because security is the flavour of the month.

        But a bug which can be exploited to give a security hole necessarily deserves a high priority, no?

        You're not a security professional

        don't pretend a bug is more important because security is the flavour of the month

        A bug which enables a remote attacker to compromise a server is necessarily a serious one, no? I really don't get what your point is with this flavour of the month thing.

      • Actually, I am a security professional, working for one of the largest security companies in the industry.

        It's clear you are not however.

        • > Actually, I am a security professional, working for one of the largest security companies in the industry.

          Hm, let me guess. You work for Microsoft, in the team developing Microsoft Security Essentials?

  • by Anonymous Coward

    'A bug this serious only comes out once every couple years.'

    ....in the time it took to fix this bug they got two more just as bad?

    One step forward, two steps back.

  • are demotions or dismissal. let alone actual proof. in a four-year administration.
  • by Anonymous Coward

    count the # of remote exploits patches in each version of Windows and how many years between patches where the OS was vulnerable.

  • by stock ( 129999 ) * <stock@stokkie.net> on Tuesday May 13, 2014 @08:58PM (#46995637) Homepage
    The problem was well discussed in 2009 here : A tempest in a tty pot https://lwn.net/Articles/34382... [lwn.net] The result was that after a heated debate, Alan Cox was blamed for allowing old code to stay because emacs would loose terminal output and Greg KH was simmoned to stepup as the TTY maintainer. The new TTY/PTY guys became James Simmons, the Frame-buffer guy and C. Scott Ananian, the former jack-of-all-trades for the One Laptop per Child Foundation. Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.
    • by Anonymous Coward

      Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.

      Wrong. RHEL 5 isn't affected, it uses an old kernel. RHEL 6 is affected: https://bugzilla.redhat.com/sh... [redhat.com]

      This issue does not affect the versions of the Linux kernel packages as shipped
      with Red Hat Enterprise Linux 5.

      This issue does affect the versions of the Linux kernel packages as shipped
      with Red Hat Enterprise Linux 6 and Red Hat Enterpr

    • The old guy screwed up, was replaced, and the new guys screwed up too. Does that mean replace or do not replace?

        Or just that you remember old news?

      If the latter, stick to tagging dupes here.

  • by ralphtheraccoon ( 582007 ) on Wednesday May 14, 2014 @01:13AM (#46996789)

    I read through the POC, it seemed safe enough to play with, so I've tried it out on a few different servers here (CentOS & Debian Stable). On the CentOS boxes it dies before it even gets started trying to overflow into a tty, and on my Debian machine it's been going for 5 minutes (using up to 90% CPU, but still leaving the machine quite usable), and still hasn't got anywhere.

    This isn't quite the "instant ROOT ACCESS!" privilege escalation that scares keeps sysadmins up at night. (unless I'm missing something...)

  • by Megol ( 3135005 ) on Wednesday May 14, 2014 @04:22AM (#46997281)

    As something like this would be impossible with the driver executing in an isolated process. Memory corruption would still be possible of course (unless the driver was written in a secure language) but it would be local.

    • As I suggested in this thread here in Dec 2012: http://developers.slashdot.org... [slashdot.org]
      "One thing of concern to me about this (not knowing the kernel communications culture or the previous interactions of Linus and this maintainer) is whether the Linux kernel (and development community) has maybe reached some point where old development methods are breaking down in trying to support an every growing monolithic kernel approach? I initially [resisted] using Linux in the 1990s because I knew there were alternative a

  • by astar ( 203020 ) <max.stalnaker@gmail.com> on Wednesday May 14, 2014 @01:23PM (#47001383) Homepage

    Openbsd defines any potential security issue as a bug. Emphasis potential. The interesting actual exploits these days are sometimes 15 unexploitable glitches strung together.

    The Linux kernel is oriented towards supporting all the cutting edge hardware. This is not going to make security very practical. Openbsd is, ah, stodgy. But what openbsd brags on is "no remote holes in the default install" not "no local exploits".

    I think that Linus cannot fix this sort of issue. Theo could take lessons from Linus on nasty around systemd but Linus has not been consistently nasty and I think it too late.

    Send Theo money.

You know you've landed gear-up when it takes full power to taxi.

Working...