Serious Linux Kernel Vulnerability Patched (threatpost.com) 85
msm1267 writes: A patch for a critical Linux kernel flaw, present in the code since 2012, is expected to be pushed out today. The vulnerability affects versions 3.8 and higher, said researchers at startup Perception Point who discovered the vulnerability. The flaw also extends to two-thirds of Android devices, the company added. An attacker would require local access to exploit the vulnerability on a Linux server. A malicious mobile app would get the job done on an Android device. The vulnerability is a reference leak that lives in the keyring facility built into the various flavors of Linux. The keyring encrypts and stores login information, encryption keys and certificates, and makes them available to applications. Here's Perception Point's explanation of the problem.
Local user to root on server is serious (Score:1, Insightful)
The summary downplays the threat to Linux servers with how the "local access required" is phrased. The PoC provided successfully escalates privileges from a local user to root. This is a very serious issue with serious remote exploitation risk.
Re: (Score:1)
1. Install Debian 7. Use it for over a year with no problems at all.
Well, apart from some problems where NFS didn't start because the sysvinit tried to mount devices before the network was up.
2. Upgrade Debian 7 to Debian 8. Systemd should be installed.
3. Reboot the computer.
4. Observe that something obscure and non-obvious with systemd prevents the system from booting fully. Try in vain to debug the problem, fighting with binary logs the whole time.
Nope, failed at this step. All my machines are booting with systemd.
Re: (Score:2)
6. Install FreeBSD 10. Now the problem is completely fixed.
And replaced by a whole new set of problems. Problems solved long ago under Linux.
Re: (Score:2)
A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.
Re: (Score:3)
A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.
Except if combined with a remote vulnerability, perhaps in the web app running locally on the server, or your web browser running on your laptop.
Re: (Score:2)
If you have a remote vulnerability, then you already have a remote vulnerability. Get at least the basic terminology right!
Re: (Score:2)
The OP managed to make the term "local vulnerability" useless. That rather strongly implies he does now know what it means. No thin ice here.
Question (Score:1)
Re: (Score:1)
For example for mounting network file systems. Could in theory be done in userspace, but on linux and windows is not.
Re: (Score:2)
Re:Question (Score:4, Informative)
One of the biggest things, is ensuring the data isn't swapped to disk in an unencrypted format.
Re:Question (Score:5, Informative)
Why does the kernel need to store login info, certificates, and the like?
While the question is legit, it has nothing to do with the bug.
The bug is a reference counting issue, where an attacker can trick the kernel to release a buffer and reallocate it to another purpose, while the original process still holds a reference to it. That process can then abuse its reference (from the old purpose) to mess with the buffer (in its new purpose) in such a way that it obtains root privileges.
It just happens that the original purpose was indeed about key management. But the bug would work just the same way if that purpose was something else. And the vulnerability even exists if this kernel feature is not used at all. It is not about disclosure of keys or anything like this.
Well, let's see how Google fixes this (Score:5, Interesting)
Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).
How are all of these Android versions in the wild going to get fixed?
Re:Well, let's see how Google fixes this (Score:5, Insightful)
How are all of these Android versions in the wild going to get fixed?
Haha they're not!
Welcome to the new way of doing things. Updates are for old fuddy duddies.
Re: (Score:2)
Re: (Score:2)
Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
And if you're not, then the recent OS update broke the whole system and they don't intend to ever fix it.
Re:Well, let's see how Google fixes this (Score:5, Insightful)
Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
I have a Nexus 4. It's still very much functional, but it's been EOL since May 2015, a scant 2.5 years after it was first released. By contrast my 8 year old eee 900 is happily running the latest version of everything.
I'm typing this from my W510 laptop (at work---yay for slacking) which is now amazingly approaching 6 years old. It works great. It's running a 2 year old version of ubuntu (14.04 LTS) which will continue to be supported for another 3 years. However, I'll almost certainly upgrade to 16.04 and the laptop will keep on trucking (the 16G of RAM has stopped it aging badly) for many years to come.
The state of mobile phones is beyond pathetic, compared to what we had for PCs.
Re: (Score:2)
Didn't the Nexus 4 get a security update in September, the same month that its third successor was officially announced?
Not according to the all-knowing wikipedia, but it might be wrong.
Re: (Score:2)
I have a Nexus 4.
Your Nexus 4 got Lollipop, which has SELinux turned on, which should block any access to this vulnerability.
Re: (Score:2)
From the article:
"The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices. Maybe we’ll talk about tricks to bypass those mitigation in upcoming blogs, anyway the most important thing for now is to patch it as soon as you can."
SELinux makes it difficult, but they're going to tell you how to get around it once it's fixed.
SELinux doesn't block access to this vulnerability, it merely makes exploitation mor
Re: (Score:3)
SELinux doesn't block access to this vulnerability, it merely makes exploitation more complex.
In Lollipop SELinux it does make it impossible. Nothing in the system used these syscalls, so access to them is completely disabled by SELinux. If you can obtain root you can disable SELinux, but if you can obtain root you don't need the vulnerability.
In Marshmallow there might be some possibility. A couple of system services started using the feature, so the SELinux configuration was partially opened up. We'll see if it turns out that there is some way to exploit it in Marshmallow. I suspect not, but if
Re: (Score:3)
Get back to work, slacker. ;P
Make it rain! (Score:2)
It is a user's great hope, and the carriers' and oems' great dread, that SuperSU [google.com] is about to find itself installed on a vast new segment of the Android market. Here's hoping!
Re: (Score:3)
They won't, and that's deliberate by the phone manufacturers and carriers. They want you to keep buying new phones every 1-2 years.
Won't buy a new phone at all unless it updates (Score:2)
I won't upgrade on a 2-year schedule--and I also won't buy from a manufacturer that doesn't support their hardware.
So the manufacturers have went from something to nothing from me.
--PM
Re: (Score:2)
Google will fix this by updating the ASOP with their fix in the latest version. Possibly even a few previous versions too.
The problem is the handset makers and carriers won't push the updates down to the handsets they support.
Re: Well, let's see how Google fixes this (Score:1)
No, the problem is that Google doesn't flex its muscles and force manufacturers and carrirers to push the fixes to the end user.
All Google has to do is to include a little clause in the terms of their agreements with manufacturers that says: must provide base system patches for at least 2 years, or else, no Google play services.
That means no play store and no Google maps. That kills the device for 99â... of the people.
They've disallowed the inclusion of play services to a manufacturer before for far mo
Re: (Score:2)
They want the court to force Samsung to offer updates for at least 2 years after the last phone of a model has been available, presently it's at best 2 years since it appeared on the market.
There is a good chance of winning as EU law stipulates a minimum warranty of 2 years.
Once it has been decided in one EU country and for the largest manufacturer it should en
Re: (Score:2)
I wouldn't be surprised to see this not get fixed on most Android devices. I'd say, other than Nexus devices, the best way to ensure one gets patches is to move to CyanogenMod.
Re: Well, let's see how Google fixes this (Score:3)
This vulnerability affects Linux kernel 3.18 and above. Android 4.1 comes with Linux kernel 3.0.31. My HTC One M8 running Marshmellow (Cyanogenmod 13) is still on kernel 3.4.0
Re: (Score:2)
HTC Desire 310 kernel version appears to be 3.4.5. There's nothing to fix.
Re: (Score:2)
Re:Well, let's see how Google fixes this (Score:4, Informative)
Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).
How are all of these Android versions in the wild going to get fixed?
Since the bug didn't appear until kernel version 3.8, Jellybean devices are safe because Jellybean has kernel 3.4.39.
Also, since Lollipop and Marshmallow have SELinux in enforcing mode, blocking access to the relevant syscalls, the bug is present but not exploitable on Lollipop and Marshmallow devices.
This means that only KitKat devices (kernel 3.10) both have the bug and don't have SELinux blocking access to it. KitKat currently has about 36% market share.
Incidentally, this also means that no Nexus devices are vulnerable. All devices newer than Galaxy Nexus have been upgraded to at least Lollipop, and so have SELinux protection. The GNex stopped at Jelly Bean, so doesn't have a vulnerable kernel (though there are other JB vulns).
Re: (Score:2)
After the stagefright bug, Google implemented a "rapid response" update system (i.e.) older systems could get security fix updates [but not necessarily feature enhancements]. This preserves the market for new devices but allows older ones to remain secure.
Google rolled this out to its various vendors (e.g. Samsung, Moto, etc.). Several of them have pledged to honor this. Thus, I recently got an OTA [security] update from Samsung for my Galaxy S3 [that was EOL] to fix stagefright.
There was a bit of NRE to p
Re: (Score:2)
They should fix it by making newer versions run intolerably slow on old devices, forcing people to buy a new phone.
*sigh* Another patch Tuesday (Score:1)
Re: (Score:2)
"but critical vulnerablilities like this seem to be becoming more and more common"
Probably a combination of the kernel becoming ever more complex (or more code anyway), and ever more scrutiny.
Re: (Score:1)
Re: (Score:2)
Because nobody's thought of code analysis before.
I'm skeptical trying to design an AI to do it would be any easier or more effective than what we're already doing.
Re: (Score:3)
We have those tools, they are called static source code analyzers, they are even very effective at identifying certain classes of bugs, though they won't find everything and the more clever the code is they worse they do as rule. Kernels unfortunately even when not being authorized by *real programers* tend to have some clever code by necessity and for performance reasons.
Re: (Score:2)
Re: (Score:2)
Serious Linux Kernel Vulnerability Patched (Score:5, Funny)
I don't run Serious Linux, so I'm fine.
Re: (Score:3)
Serious Linux users are also fine, because the flaw has been fixed :P
Time taken to overflow (Score:3)
Out of curiosity, I decided to see how long it would take to overflow. Looping 2^24 times took 7.5 seconds on my laptop, indicating overflowing the 32bit ref would take about 1/2 hour. (That works out at 2.3m syscall's per second.)
Re: (Score:1)
So on a phone, it would take about six hours, drain the entire battery, and probably cause the thing to explode...
Typo in version (Score:1)
Re: (Score:3)
Read again. Their exploit code is against 3.18, but they say that 3.8 and later is affected.
What about ESXi? (Score:1)
Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.
Re: (Score:2, Informative)
ESXi is NOT based on the Linux kernel.
It implements some driver api layers through the vmklinux module to allow Linux kernel modules to be ported to ESXi... similar to how ndiswrapper in Linux works to allow you to run windows drivers on Linux. Also ESXi 5.5 moves away from this with "native drivers" like elxnet.
The other similarity is some open source software is recompiled and included such as busybox.
IMHO it is closer to BSD then Linux... but it's actually it's own beast.
Re: (Score:2)
Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.
AC - you should know what you're talking about. Obviously you have no clue. I've been using it for years and they update all the time. It's easy to patch. I also have the free home version. Same story. Easy to patch. Just because you never bothered to look doesn't mean it's true.
A malicious mobile app (Score:2)
.
There appears to be no way to reign in the apps.
Re: (Score:2)
Re:Is it a 0-day?(no) (Score:2)
No, there is no active exploit for this right now. It's all in theory.
GOTO still considered harmful (Score:2, Insightful)
According to a comment on Phoronix ( http://www.phoronix.com/forums... [phoronix.com] ), the cause is a goto:
"And the funny thing is? The guilty line is a fucking GOTO. Everyone using this atrocious coding practice should be shot in the head." ("magika")
User "stevenc" adds: "It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function. They'd even implemented their own reference counters
Re: (Score:2)
"And the funny thing is? The guilty line is a fucking GOTO."
No; the goto wouldn't have mattered - the missing key_put() could have been put at either location, with or without the goto.
Re: (Score:2)
I hope you do understand that the fact that you _could_ do it right is not an excuse? The goto makes it easy to get an indigestible spagetti mass of code that defies code analysis and leads to this sort of bug being introduced... The problem with the goto is not that it introduces a four-letter word, but that it makes it easy to make precisely this type of mistake.
Re: (Score:2)
The same bug would have existed without the goto business:
if (keyring == new->session_keyring) {
key_put(...)
mutex_unlcok(...)
abort_creds(...)
return 0;
}
would have been just as buggy without the key_put(). The goto was neither necessary nor sufficient for this bug.
Re: (Score:1)
You dipshit. The use of goto had nothing to do with this. The use of goto's in the kernel, and in other systems programming contexts, has nothing to do with emulating Object Oriented programming. Its good old fashioned exception handling. You either use nested if-thens or goto's. If can fuckup the cleanup code in either case.
Goto spaghetti comes from going up and down in the control flow. The use of goto's to unwind during an exception is good old fashioned linear programming. If this confuses you, s
Re: (Score:2)
Do you really go through life starting conversations with "you dipshit"? How many times have you been hit in the face for that yet?
Oh wait, is that you Linus?
Re:GOTO still considered harmful (Score:4, Informative)
Guess what! it has nothing to do with OOP emulation. All cleanup in a C program has to be done explicitly by the developer, be it coded in object-oriented, functional, imperative or whatever the paradigm-of-the-week is.
Furthermore, the way kernel devs use goto for cleanup is one of the ways that actually keeps the code simpler and less prone to errors. There are a few alternatives to do cleanup in complex code: