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

Re:Question

[castionsosa]

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

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