Serious Linux Kernel Vulnerability Patched (threatpost.com)

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.

Comments

Well, let's see how Google fixes this

[cerberusss]

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

[serviscope_minor]

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:Well, let's see how Google fixes this

[dreamchaser]

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.

Re:Well, let's see how Google fixes this

[Geordish]

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

[castionsosa]

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

[serviscope_minor]

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: Well, let's see how Google fixes this

[the_humeister]

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:Well, let's see how Google fixes this

[shawn2772]

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:Well, let's see how Google fixes this

[antdude]

Get back to work, slacker. ;P

Re:Well, let's see how Google fixes this

[shawn2772]

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 there is Marshmallow devices are also quite likely to be getting security updates, so most -- if not all -- will be patched very soon.

KitKat is the vulnerable population. The portion of it that is using 3.10. After digging a bit more, I found that the Nexus KitKat devices were still on 3.4, and that was the configuration Google recommended. Some OEMs switched to 3.10, though. I have no idea what the market share of KitKat w/3.10 is.

Serious Linux Kernel Vulnerability Patched

[Anonymous Coward]

I don't run Serious Linux, so I'm fine.

Re:Serious Linux Kernel Vulnerability Patched

[Rik Sweeney]

Serious Linux users are also fine, because the flaw has been fixed :P

Re:Question

[castionsosa]

One of the biggest things, is ensuring the data isn't swapped to disk in an unencrypted format.

Time taken to overflow

[John Allsup]

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:Question

[ArsenneLupin]

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.

Re:Typo in version

[gweihir]

Read again. Their exploit code is against 3.18, but they say that 3.8 and later is affected.

Re:*sigh* Another patch Tuesday

[DarkOx]

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:Local user to root on server is serious

[kthreadd]

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:What about ESXi?

[Anonymous Coward]

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:GOTO still considered harmful

[andyn]

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:

1. Don't do error checks. In your average C101 homework it's often assumed that many syscalls cannot fail. Obviously, the absolute minimum required in a real world program is a simple assert that stops the program before it can misbehave. Any real-world program that cannot lose data or crash the whole system such as office programs, databases and kernels obviously cannot do this.
2. Do an early return and clean up all data so far. Very error prone as the cleanup code has to be replicated in multiple places.
3. if/do-while(0)-break wrapping of code. Easy as long as there is one tier of resources to allocate. Any more and the function becomes arrow code.
4. Wrap the constructors and destructors in a macro to emulate RAII. The result is still arrowish, although the cleanup is harder to fail. Not allowed in many projects due to an undeserved loathing of macros.
5. Split the code into multiple functions. Now you have to pass around the state in function parameters. Having the code split into multiple functions makes the it more prone to logic errors.
6. Use goto to jump to the cleanup section. All relevant code is kept in the same function and the code between alllocations and frees stays flat and concise.