Slashdot Mirror
5-Year-Old Critical Linux Vulnerability Patched (threatpost.com)
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."
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."
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.
The real story here, is that 4 days after the vulnerability was made known to the devs, a patch was released.
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.
Give a five-year-old a nod, he'll come back with all kinds of bait-and-switch naughtiness.
With the patch of this five-year old bug, this is finally the year of Linux on the Desktop.
If an attacker is in the same room as your system, you're already pwnd.
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.
... 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.
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.
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.
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.
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.
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.
So basically, a classic, well known TOCTTOU vulnerability.
Higher Logics: where programming meets science.
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
Not everyone who dislikes Linux' design is a MS-shill. Could also be Andrew S. Tanenbaum.
Moron.
"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...
From the Shakespeare AU where Othello encounters the Wierd Sisters from Macbeth?
Inheritance is the sincerest form of nepotism.
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/
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.
When you gave hundreds of undergraduates accounts on Sun of Vax machines. Local user access SHOULD NOT invariably lead to a root exploit.
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)
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.
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.
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?!?!?
needlessly complicated
That needless complexity was actually power. Linux threading is incredibly primitive.
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.
... 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?
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.
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.
Linux is unsafe at any speed.
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
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.
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.
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?
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.
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().