Slashdot Mirror

← Back to Stories (view on slashdot.org)

5-Year-Old Critical Linux Vulnerability Patched (threatpost.com)

Posted by EditorDavid on from the local-Linux-attacks dept.

msm1267 quotes Kaspersky Lab's ThreatPost: A critical, local code-execution vulnerability in the Linux kernel was patched more than a week ago, continuing a run of serious security issues in the operating system, most of which have been hiding in the code for years. Details on the vulnerability were published Tuesday by researcher Philip Pettersson, who said the vulnerable code was introd in August 2011.

A patch was pushed to the mainline Linux kernel December 2, four days after it was privately disclosed. Pettersson has developed a proof-of-concept exploit specifically for Ubuntu distributions, but told Threatpost his attack could be ported to other distros with some changes. The vulnerability is a race condition that was discovered in the af_packet implementation in the Linux kernel, and Pettersson said that a local attacker could exploit the bug to gain kernel code execution from unprivileged processes. He said the bug cannot be exploited remotely.
"Basically it's a bait-and-switch," the researcher told Threatpost. "The bug allows you to trick the kernel into thinking it is working with one kind of object, while you actually switched it to another kind of object before it could react."

68 comments

  1. Not surprising by Anonymous Coward · · Score: -1

    Anyone who has ever looked at linux kernel (or any major software project) code knows that it's mostly dreams and wishes that makes it work.
    Especially with threaded code like a kernel where you have no clue when and where something can change, and no clear guidelines for locking.
    Code review exists, but that only takes you so far.
    Especially if you change something minor in one place that violates assumptions made in completely different parts of the code.
    The amazing thing to me is that the linux kernel doesn't even have a testsuite like GCC or binutils (correct me if I'm wrong).

    1. Re:Not surprising by godrik · · Score: 2, Informative

      The amazing thing to me is that the linux kernel doesn't even have a testsuite like GCC or binutils (correct me if I'm wrong).

      There is a test suite here.

    2. Re:Not surprising by Anonymous Coward · · Score: 0

      I didn't see it.
      Unless you meant the entire distribution, which isn't really a test suite unless they have some automated scripts to test various drivers and system calls.

    3. Re:Not surprising by Anonymous Coward · · Score: 1, Interesting

      If you want to go this way, maybe gentoo could be considered a test suite, surely not archlinux.

      Peoples please stop praising arch for the wrong reasons.
      Namely here, arch delivers binaries and this for a quite restricted set of architectures
      Even with AUR, you ll get mainly peoples compiling for the same plateformes, with the same options, and mostly compiling apps not the kernel.

      Obviously posting as AC, with the number of arch fanboys, this will get downvoted to hell.

    4. Re:Not surprising by Anonymous Coward · · Score: 5, Interesting

      In my OS class during my UG CS degree we were writing a small OS. By the time we got to threading we were bitching about how hard it was in *nix so our prof cracked the hood on the Windows threading APIs... We collectively shut the hell up when we saw how hideous and needlessly complicated it was compared to what we were working with.

      It turns out that Linux has WAY less bugs than Windows or Mac despite being dreams and wishes...and this is with completely open code base. https://www.cvedetails.com/

      Windows is a colostomy bag of code in comparison and it you think you've found a way to improve some part Linux you should write up and submit a patch.

    5. Re:Not surprising by Anonymous Coward · · Score: -1

      What the fuck does that have to do with Linux? Can there be ANY article about bugs or exploits in Linux without some fucking retard going *herp durp* Windoze haz bugz!!!

    6. Re: Not surprising by Type44Q · · Score: 0

      He posts a successful rebuttal to your anonymous MS-shill bullshit and that's the best that you're able to come up with?? Priceless.

    7. Re: Not surprising by Anonymous Coward · · Score: 1

      Not everyone who dislikes Linux' design is a MS-shill. Could also be Andrew S. Tanenbaum.

    8. Re: Not surprising by Anonymous Coward · · Score: 0

      He was totally right to be critical of Linus, he quickly stole all his Minix costumers.

      Minix is now BSD licensed.
      http://www.minix3.org/

    9. Re:Not surprising by Anonymous Coward · · Score: 0

      Threading in Windows is actually significantly better and more efficient than in Unix. Vice Versa forking is significantly better and more efficient in Unix than in Windows. Your lecturer is simply an idiot.

    10. Re:Not surprising by Anonymous Coward · · Score: 0

      needlessly complicated

      That needless complexity was actually power. Linux threading is incredibly primitive.

    11. Re:Not surprising by Anonymous Coward · · Score: 0

      Effective (that is: maintainable, reliable and cost-effective) testing depends on abstractions... stubbing or virtualizing certain aspects of the program so that a portion can be tested in a way that produces actionable results, and plumbing in instrumentation to be able to inspect the result.

      The Linux kernel is hard to test in this way, because it is the abstraction. There are no more layers underneath it to implement stubbing. Sure, you could run Linux in a virtual machine, but then you are testing the virtio drivers or some other specific set of drivers for devices that the VM emulates, and the VM's emulation of such devices is likely to not be 100% accurate.

      Also, automated testing is generally a defense against regressions rather than a guarantee of correctness. It's quite common for a bug to not be caught by testing because if the author thought to test it then the author wouldn't have missed the edge case that led to the bug in the first place. This is particularly true of security bugs, since they generally depend on making a system operate in conditions that the author didn't consider, and thus would not have tested.

      There are of course other techniques for analyzing software that are more appropriate for this sort of testing. For example, we can "fuzz" systems by sending them garbage and seeing if they crash by executing codepaths the author didn't consider. We can also release them into the wild and let the user community at large test and verify the software, which of course creates the risk that the group or individual that finds an issue might not disclose it responsibly or at all.

    12. Re:Not surprising by ebvwfbw · · Score: 1

      You have no idea what you're talking about. I started with it before it was even released in 1992. It's been very much tested and reviewed. That doesn't mean you catch everything. There are things that happen that you never anticipated. An error occurs. If you can exploit it, you might be able to do something unexpected such as take over the kernel space. If you do, tell them about it and we'll fix it. It's becoming very very hard to break out of that jail.

      This is in huge contrast to the Windows kernel. Just a patched up program loader that sucks and is full of holes. I have to manage both and I can tell you that Windows is really full of a LOT of holes. Even for things like group policies they distribute in the clear, even if it has a password in it such as for their laps product. I have to think they don't care about security. Just send a truckload of money to them.

    13. Re: Not surprising by jeremyp · · Score: 1

      He posts a successful rebuttal to your anonymous MS-shill bullshit

      The post which he allegedly rebutted doesn't say anything about Windows. So, no it was not a successful rebuttal.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    14. Re: Not surprising by Anonymous Coward · · Score: 0

      Different AC here, too lazy to log in. It actually helps to get a post downvote, and the downvote only takes -1 of your karma. On the other hand, they day after you are downvoted you get 5 moderator points.

    15. Re:Not surprising by SivDotnet · · Score: 1

      So where's the great assertion that open source code is being eyeballed by millions of users so that it's intrinsically better than closed source as all these viewers would spot the error and report it or fix it if this has been in the kernel for many years and as yet unfixed.

      I think in reality Open source has many users but very few are capable of reading the code and spotting the errors any more than the equivalent Windows users are, so the whole premise that Open Source code is any better than closed source code is a fallacy!

      I think open source has been lucky to date that relatively few malicious hackers have spent time poking around in the code so it was the small numbers of target systems that was keeping the vulnerabilities down not the superiority of the code. I think open source needs to get off its high horse and get some serious security specialists to go through the code and identify the weaknesses and get the code fixed. Open SSL should have been the alarm bell that triggered this.

      Siv

      --
      Martley, Near Worcester UK.
    16. Re:Not surprising by Anonymous Coward · · Score: 0

      You have no idea what you're talking about. I started with it before it was even released in 1992. It's been very much tested and reviewed. That doesn't mean you catch everything. There are things that happen that you never anticipated. An error occurs. If you can exploit it, you might be able to do something unexpected such as take over the kernel space. If you do, tell them about it and we'll fix it. It's becoming very very hard to break out of that jail.

      It's okay if you don't start with a full set of tests. As you fix problems though, you add tests to make sure that they don't happen again. As you point out, it's been 24 years.... does Linux have a regression test suite?

    17. Re:Not surprising by sad_ · · Score: 1

      I think in reality Open source has many users but very few are capable of reading the code and spotting the errors any more than the equivalent Windows users are, so the whole premise that Open Source code is any better than closed source code is a fallacy!

      windows has many users, but very few are capable of reading code and spotting errors, too bad they can't fix it. At least on Linux, as few knowledgable people that may be using it, they have that option.

      --
      On a long enough timeline, the survival rate for everyone drops to zero.
    18. Re:Not surprising by Anonymous Coward · · Score: 0

      I don't think you know what you're talking about. In many ways, it's the other way around. You're limited to having 64 handles in the equivalent of a thread group in Windows. If you want to have more, you have to have a silly tree-like system, with a process who's only purpose is to spawn and hold 64 handles, each of which spawn some number of threads. Likewise, forking is, in some ways, better in Windows because of the CreateProcess API. Sure, it's more efficient in Linux due to its heavy usage of CoW and extreme emphasis on performance (even with the hit of using fork+exec), but the fact that Windows returns handles makes it so much easier to manipulate processes. Linux returns a PID and you can *only* manipulate via that PID, so you've got race conditions and more. Imagine if, instead, fork() returned a file descriptor, and the PID was just for reference. It would be a much better world. You wouldn't have to worry about wait4() not working because you're no longer the parent of a given process. Of course, if Linux had kqueue() like many *BSDs and OSX has, much of that problem would be solved, so it's certainly not an intrinsic problem with *nix, just with Linux's epoll() not being a replacement for kqueue().

  2. By the twitching of my thumb by Anonymous Coward · · Score: -1

    By the twitching of my thumb ... something Muslim this way comes

  3. Hiding in the code for years?! by Anonymous Coward · · Score: 0, Insightful

    I don't think so! As we all know, Linux users all look at the source code and understand every line of it and would have seen this issue as soon as it appeared.

    This is just more fake news and FUD to scare people away from Linux and FOSS in general.

    1. Re:Hiding in the code for years?! by Anonymous Coward · · Score: -1

      Well, we know for certain that Windows and Mac OS X users don't know jack.

    2. Re:Hiding in the code for years?! by Anonymous Coward · · Score: 0

      Yes, because proprietary code has such a stellar record when it comes to security and the developers never, quite deliberately, let critical bugs linger for years without addressing them. Oh wait...

      Nobody said FOSS is bug free, just that it's better than the alternative.

    3. Re:Hiding in the code for years?! by Hylandr · · Score: 0

      Back Oriface.

      Just saying.

      --
      ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
    4. Re:Hiding in the code for years?! by Yvan256 · · Score: 1

      Mac user: Oh yeah? Let me see...
      (open Contacts application)
      Mac user: You're right, I don't know anyone named Jack.

  4. Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 5, Insightful

    The real story here, is that 4 days after the vulnerability was made known to the devs, a patch was released.

    1. Re:Bug discovered, 4 days later, patch released. by Abu+of+unruley+kids · · Score: 2

      ^ This

    2. Re:Bug discovered, 4 days later, patch released. by Kjella · · Score: 1

      The real story here, is that 4 days after the vulnerability was made known to the devs, a patch was released.

      Why? If no bad guys have found it the difference between four days or and three months is of little difference. If the bad guys have found it (or worse yet, planted it) the difference between five years and four days and five years and three months is also of little difference. Not the kind of casual bad guys that deal with cryptolockers and botnets and identity theft, if they found it you'd probably see it in the wild and exposed. But targeted attacks for industrial espionage and such could probably use it in narrow attacks for a long time before being spotted.

      --
      Live today, because you never know what tomorrow brings
    3. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 1

      No. That's the story you want people to talk about as a distraction to the real story. "Look guys. As soon as someone bothered to actually check the code we fixed it so fast!!" SO FAST!!!

    4. Re:Bug discovered, 4 days later, patch released. by Abu+of+unruley+kids · · Score: 1

      Kernel code isn't blindly put in to the code base. Linus and his trusted few do a great job, at weaving out the garbage submissions, for the most part. They aren't as affective as OpenBSD, with their useful paranoid code audits. If your concerned about future instances like this. Please contribute your time, not your tears.

    5. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 0

      Why? If no bad guys have found it the difference between four days or and three months is of little difference.

      Because if a company is willing to hold off for three months to fix a problem, they may wait 5 years.

      If the bad guys have found it (or worse yet, planted it) the difference between five years and four days and five years and three months is also of little difference.

      Granted. And generally a vulnerability of this magnitude being out for 5 years is plain bad, so the attempt by the GP to try to spin it into "4 days" is absurd.

      Not the kind of casual bad guys that deal with cryptolockers and botnets and identity theft, if they found it you'd probably see it in the wild and exposed. But targeted attacks for industrial espionage and such could probably use it in narrow attacks for a long time before being spotted.

      I'd imagine most of them just go the social engineering route. It tends to be a lot more reliable and most system admins, if they discover it after the fact, will be very disinclined to divulge that they're the weakest link in your security system.

    6. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 1

      I'd have to use Linux to be the one crying.

    7. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 0

      The point is the bad guys had no better visibility than everyone else, unlike closed source,where bad guys, by definition, will gladly steal the codebase or traffic in it, and the codemonkeys at the business are busy writing new code or fixing bugs that users have already found and complained enough about to go and do an audit of the code, which doesn't generate new income.

    8. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 0

      not sure I agree. This was a 5 year old vulnerability which either every bad guy new about in which case it should have been immediately disclosed, or it was completely unknown prior to this in which case they rushed out a patch that hasn't gone through proper testing.

    9. Re:Bug discovered, 4 days later, patch released. by antdude · · Score: 1

      I don't see it for Debian stable/Jessie so far. :P

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
    10. Re:Bug discovered, 4 days later, patch released. by Anonymous Coward · · Score: 1

      The point is the bad guys had no better visibility than everyone else, unlike closed source,where bad guys, by definition, will gladly steal the codebase or traffic in it, and the codemonkeys at the business are busy writing new code or fixing bugs that users have already found and complained enough about to go and do an audit of the code, which doesn't generate new income.

      The whole thing shows open source or closed the problem is identical. people generally aren't looking at the code from a security perspective except those few doing security research or bad actors, both of those groups have all the code access they require.

  5. Be careful... by __aaclcg7560 · · Score: 0

    Give a five-year-old a nod, he'll come back with all kinds of bait-and-switch naughtiness.

  6. Netcraft confirms it by Anonymous Coward · · Score: 0

    With the patch of this five-year old bug, this is finally the year of Linux on the Desktop.

  7. bug cannot be exploited remotely by Anonymous Coward · · Score: 1, Insightful

    If an attacker is in the same room as your system, you're already pwnd.

    1. Re:bug cannot be exploited remotely by bill_mcgonigle · · Score: 3, Insightful

      If an attacker is in the same room as your system, you're already pwnd.

      This bug can't be exploited remotely. Other bugs can, to get a local user shell, then you stack this one on top.

      They're all problems.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:bug cannot be exploited remotely by Anonymous Coward · · Score: 0

      Yeah, except the fact that code runs as local users all the time. In fact every time you visit a website, that is code running as a local user on a server.

    3. Re:bug cannot be exploited remotely by Anonymous Coward · · Score: 0

      So you'd need an exploit in that service first...then you could PE with this already patched bug and a time machine.

    4. Re:bug cannot be exploited remotely by buchner.johannes · · Score: 1

      You could be ssh-d into the machine as a user, and this will give you root privileges. No physical proximity needed.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    5. Re:bug cannot be exploited remotely by KiloByte · · Score: 1

      In 99.9% cases, if you pwn that local user, you control everything that server is doing. Applies to client machines, too.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    6. Re: bug cannot be exploited remotely by Anonymous Coward · · Score: 0

      And to get ssh access might just take a phishing or social engineering attack... This kernel bug is a significant issue.

  8. The five year old ... by CaptainDork · · Score: 1

    ... is out of intensive care and is rocking the eye patch.

    --
    It little behooves the best of us to comment on the rest of us.
  9. Rushing out a parch... by Anonymous Coward · · Score: -1

    Usually just leads to more bugs.

  10. it's ruining everything! by Gravis+Zero · · Score: 0

    The vulnerability is a race condition that was discovered in the af_packet implementation in the Linux kernel

    racism is ruining our country... and now our kernel too? IS NOTHING SACRED ANYMORE?! ;)

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:it's ruining everything! by Anonymous Coward · · Score: -1

      Even medicine is racist: http://www.dailymail.co.uk/health/article-351627/Black-heart-drug-causes-outrage.html

  11. how does one patch "the user"? by Anonymous Coward · · Score: 0

    No matter what happens, and how long it takes for software bugs to be fixed, "the user" will always be the critical vulnerability in any/all computer system.

    It doesn't matter how robust a system is as long as there are user whose passwords are "123456" or "password", and that social engineering is the gaping hole in the system.

    Why would one spend energy exploiting software when one can send an email to a user who will "gladly" install spy-ware and ransom-ware on their computer.

  12. Classic TOCTTOU by naasking · · Score: 3, Informative

    So basically, a classic, well known TOCTTOU vulnerability.

    --
    Higher Logics: where programming meets science.
  13. Haha oh man the excuses by ArchieBunker · · Score: 1, Insightful

    What happened to the "many eyes" argument? Oh yeah that died along with heartbleed and the old SSL codebase.

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
    1. Re:Haha oh man the excuses by Anonymous Coward · · Score: 0

      Oh, the many eyes thing. Yes, it works. It just takes 5 years to fix it because "many eyes" means the 18 people that look at core Linux kernel code AND are competent enough to find bugs in it. I mean, I would look at it - but I wouldn't know what the hell I was reading.

    2. Re:Haha oh man the excuses by Tablizer · · Score: 1

      Need MORE eyes.

      Good security needs both careful design and more eyes.

      --
      Table-ized A.I.
    3. Re:Haha oh man the excuses by Anonymous Coward · · Score: 0

      It never meant that many eyes make bugs easy to find, it means that having more people involved increases the likelyhood that one of them understands the problem and knows how to fix it. It makes solving bugs easier, not necessarily finding them. From the source:

      My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.''

    4. Re:Haha oh man the excuses by sjames · · Score: 1

      Part of the issue for this particular bug is that few really looked at it for a simple reason: You have to have CAP_RAW_PACKET in order to exploit it, and to get that you had to be root (until recently).

    5. Re: Haha oh man the excuses by Anonymous Coward · · Score: 0

      There are plenty of enemy eyes looking for exploits that can be used for national advantage, you will just never hear about what they find.

  14. Uh, this is the result of many eyes. by Anonymous Coward · · Score: 0

    Moron.

  15. Ho hum by JustAnotherOldGuy · · Score: 1

    "He said the bug cannot be exploited remotely."

    In other words, "yawn". If you have physical access to a machine all bets are off.

    --
    Just cruising through this digital world at 33 1/3 rpm...
  16. Spoiler warning by fibonacci8 · · Score: 1

    From the Shakespeare AU where Othello encounters the Wierd Sisters from Macbeth?

    --
    Inheritance is the sincerest form of nepotism.
  17. non-magic software by Anonymous Coward · · Score: 0

    Yea, unfortunately the "many eyes" approach was not based on rainbows and magic. It was a description of an open review process on ordinary non-magic software.

  18. There was a time where this wasn't the assumption by Anonymous Coward · · Score: 0

    When you gave hundreds of undergraduates accounts on Sun of Vax machines. Local user access SHOULD NOT invariably lead to a root exploit.

  19. Did Microsoft paid to write article in such way? by NuclearCat · · Score: 2

    This bug need CAP_NET_ADMIN privileges, which are VERY rarely enabled for typical user, because they will let you screw network configuration and sniff on traffic (which is almost equal to root privileges in our networking days)

  20. Re:There was a time where this wasn't the assumpti by Anonymous Coward · · Score: 0

    given the general lack of security on Vax it most definitely did invariably lead to root access. Same on Sun machines though at least the security there was a little better.

  21. Yes, bugs in both codes are still bugs by Anonymous Coward · · Score: 0

    But the way they're treated AND the way they are found is entirely different. And when one outsider group has access to the code via theft and the other equivalent has via legal means, one "outsider" group will be using it for criminal acts, the other one will be diluted by people who AREN'T pre-selected from the criminal classes.

    Why are you pretending that no such difference doesn't exist WHEN YOU REPLIED TO ME TELLING YOU WHAT THEY WERE?!?!?

  22. Versions affected by gustygolf · · Score: 1

    In case anyone cares, this code was first introduced in Linux 3.2.

    This is for those of us who use uname -r to check their kernel version, not the year it was checked out from the kernel repos.

    --
    "Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
  23. openssl, kernel, ... by Anonymous Coward · · Score: 0

    ... and systemd

    Both openssl and kernel recently received security fixes for years old vulnerabilities. Both are well reviewed (I guess and hope). How many of such vulnerabilities resides in those 270 k lines of systemd code do you think? Are those lines of code also reviewed as much as the kernel's?

  24. Unsafe by Anonymous Coward · · Score: 0

    Linux is unsafe at any speed.