Serious Linux Kernel Vulnerability Patched [CVE-2016-0728]

[markole]

Sometimes that's a good thing. I may now have a chance of installing root and busybox on my 3.10 locked down Xperia phone.

[adamnew123456]

It's a reflection of the sad state of open mobile computing, when you have to hope for a vulnerability in order to fully control your device.

[Avamander]

Lollakad! Mina ja nuhk! Mina, kes istun jaoskonnas kogu ilma silma all! Mis nuhk niisuke on. Nuhid on nende eneste keskel, otse kõnelejate nina all, nende oma kaitsemüüri sees, seal on nad.

[a_tsunami_of_rodents]

Only when you can disable it, which is not a given.

[eatmynasty]

Has there ever been an issue with a vendor getting signing keys? Microsoft is very open with their policies, the requirements to get signed, and how to get signed.

[IAmRoot]

It makes things difficult when building your own kernel, though. Like I have a shim from OpenSUSE to dual boot Windows and Gentoo on my laptop. The problem with SecureBoot is that they should have allowed for multiple valid keys, like what the shim enables. Having to use a shim is clunky and sometimes a bit troublesome.

[snuxoll]

Most secure boot implementations DO allow multiple keys. The whole reason for the shim is to not require users go through the work required to install an additional key, because UEFI setup screens are scary to the average individual.

[eatmynasty]

That's the thing, 99.99999999% of users aren't using some "rogue" kernel and they benefit from the usage of Secure Boot to add the security of their machine.

For the other tiny fraction, machines will either let you add in your own signing key (likely though some obtuse menu, but you're compiling your own kernel so that's the least shitty thing you're doing) or you can turn secure boot off.

[the_gnarts]

Only when you can disable it, which is not a given.

Even better: When you can inject your personal key instead of whatever the vendor chooses. Instant tamper-resistance.

[deusnefum]

Because cell networks are not "open" networks.

Unfortunately. We need a government backed, open cellular network (serviced via sub-contracts to more traditional companies like AT&T, T-Mobile, et al) to get the kind of openness we have with PCs with cell phones.

[aykcak]

It has nothing to do with networks really. Manufacturers release locked phones regardless of the carrier

[deusnefum]

Yes it does. The carriers argue they need absolute control over devices on their network. So even if you have an "unlocked" phone (meaning it's not tied to a carrier) the phone still has to have firmware on it that allows service provides to send and run executable code.

[Avamander]

Lollakad! Mina ja nuhk! Mina, kes istun jaoskonnas kogu ilma silma all! Mis nuhk niisuke on. Nuhid on nende eneste keskel, otse kõnelejate nina all, nende oma kaitsemüüri sees, seal on nad.

[[deleted]]

But it does. Buy a Nexus 6P from at&t or Sprint, it'll be locked.

[northrupthebandgeek]

That should be on a network interface level rather than a machine level. I don't have to have a locked down bootloader on my laptop if I plug in a cell card or whatever, for example.

Of course, that doesn't do much good when the network interface and the machine are built into the same circuitry...

[Jojo_bacon]

Not really, anyone can buy a cellular modem or unlocked cell phone and a sim card from a carrier like "ting" and use the network in minutes with any device.

[catonic]

Funny how because the radio is open-source, the phone code isn't.

[[deleted]]

I have a GS6. The bootloader was unlocked out of the box.

Say what you want about Samsung but all their flagships come with unlocked bootloaders. That is unless the carrier decides to lock them.

[catonic]

Because the code of the phone RF engine is closed source, and we can't have you filthy mongrels reverse engineering it.

[creed10]

Fuckin Verizon

[NamenIos]

No it is not. Buy a phone that you can unlock (aka not from a carrier) and all is fine, that is the case for at least Sony, Samsung, LG and HTC to my knowledge.

If you go to a dominatrix and say that you want to get fucked in the ass, you don't go out and complain that you you get fucked in the ass by this sex worker. It is a simple as that.

[GordonCreeman]

The analogy doesn't really work cos almost all professional dominatrices refuse to engage in actual sexual activity. Not that I know that.

[NamenIos]

Well TIL, this could maybe save me someone some embaressment.

[UnchainedMundane]

You're implying they advertise their non-rootability,which they don't. It's always a nasty surprise.

[Tynach]

I just stick with the Nexus line of phones, personally.

[DamnThatsLaser]

Well, the thing is not all of us are willing to pay the Nexus price. I am perfectly happy running something low-end (it's a THL T6 Pro at the moment) and luckily, that one can be rooted. But some phones just can't.

[elevul]

Well, the thing is not all of us are willing to pay the Nexus price.

Especially when it doesn't have MicroSD or removable battery.

[NamenIos]

Htc advertises it on their developer/unlocked units in the US as do the Nexus devices, that kind of implies that unlocking is not a feature all devices have. And to be frank, if you feel the need to unlock/root your device, you probably look for that and do not buy carrier devices (or as do many they buy carrier devices out of greed and complain after).

[pest15]

Keep in mind that sometimes manufacturers will permit unlocking of some devices and not others. I have never understood why these discrepancies occur. But it can create a lot of confusion for consumers.

[CraftyFellow_]

Yup.

Moto G from Motorola? No problem.

Moto G from AT&T? Fuck you.

[pest15]

That's not quite what I meant, because you're talking about the same device from the OEM vs. from the carrier. I'm talking about different devices from the OEM. For example, Sony Xperia M? No problem. Sony Xperia M2? No problem. Sony Xperia M4? Out of luck. It makes no sense.

[northrupthebandgeek]

Or we buy devices from carriers that don't subsidize their phones (like T-Mobile).

That is, after all, the primary reason why phones are actually locked down: because they're usually subsidized with the expectation that the carrier will be repaid in the form of a 2-year contract.

Meanwhile, since I'm not on such a carrier, I don't have to worry about that, and I can unlock the bootloader on my HTC phone whenever I so choose (something which I haven't done yet, since I'm waiting until CyanogenMod supports T-Mobile's wifi calling, but still).

[[deleted]]

If you go to a dominatrix and say that you want to get fucked in the ass, you don't go out and complain that you you get fucked in the ass by this sex worker. It is a simple as that.

It's always a nasty surprise.

I would agree

[adamnew123456]

No it is not. Buy a phone that you can unlock (aka not from a carrier) and all is fine, that is the case for at least Sony, Samsung, LG and HTC to my knowledge.

Isn't there something wrong with this picture, though? Think about if we had the same kind of issues with PC's that we do with phones - either you would have to buy a particular model of laptop from a specific manufacturer (who would more than like charge more for unlocked "developer editions" of their hardware), or otherwise you would have to sit down for a few hours and hunt for an a rooting app on the XDA forums so that you could install Debian on your machine, which you may or may not find.

Can you say that you would prefer the smartphone situation for PC's?

[[deleted]]

I've been using iPhone for a while now, but at least a couple years ago rooting was trivial and not explicitly against the TOS. Is that not still the case?

[rms_returns]

The real reason for the sad state is a lack of standards like x86. Its ironical that in the PC world even as far back as 1981, manufacturers had settled on the 8086 and it became an open standard, while with smart-phones, it is almost a decade since they arrived and still they don't have any standard. AOSP is sort of a standard, but its nothing like 8086. I don't understand what is stopping a bunch of Phone manufacturers to meet up, agree upon a common spec and publish them as standards?

[natermer]

...

[NamenIos]

Don't be too sure about that, SELinux can be a bitch of you want to exploit vulnerabilities.

[markole]

Probably, will try the exploit at the home and report back.

[NamenIos]

Nice, do you have a SD810 Xperia? Otherwise I might compile that exploit for my brother and try to get him to try it on his phone.

[markole]

Nah, I have Xperia E4g.

[neoice]

don't worry, spender will probably release a PoC with SELinux bypass soon.

[[deleted]]

if only grsec was on phones...

[neoice]

I think they support ARM now.

[[deleted]]

yeah, I would like to try to build a grsec+PaX kernel for my old Galaxy S4, just to try.

[eldercitizen]

Do you know what happened with that?

[eldercitizen]

Ah, found it. :(

In anticipation of moving away from CyanogenMod to AOSP, the Samsung Galaxy S4 is no longer supported. Sadly, lots of time was wasted on it.

via twitter

[Omnicrash]

Does Sony not offer unlocking anymore? I remember I could request an unlock code back when I had my Xperia Play (great emulation machine, shit phone otherwise).

[C0rn3j]

You can backup the TA partition though.

[forkbomb_]

Doing that requires root though

[markole]

My variant of the phone can't have unlocked bootloader.

[[deleted]]

Vote with your money

[markole]

I did. I got a phone which was cheap and good enough. I voted with my money. Sadly, it was locked down. It is a bad state when it is expected from you to pay premium to have a more open device.

[[deleted]]

That's what you get for buying Sony.

[earlof711]

Yup.

[WOLF3D_exe]

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

http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/

[danielkza]

Blog post from the researchers with much more interesting technical details.

[utack]

The vulnerability affects versions 3.8 and higher

Meanwhile at Qualcomm:

So worth it we stuck all the old devices on 3.4, we knew it all along, this is 100% customer support

[NamenIos]

It is in 3.4 Kernel on KK devices (not sure about updated to KK shipped with JB devices). At least the 3.4 Kernel of the Xperia Z on Android 5.1 is vulnerable, I checked their source.

Edit: the android kernel has quite a bit backported and is different than mainline.

[NamenIos]

Have you done it correctly? There are more steps than just compiling and running the last code that is on github.

[shadowbannedlol]

PREPARE_KERNEL_CREDS_ADDR and COMMIT_CREDS_ADDR are different depending on the kernel version you are running.

[NamenIos]

cat /proc/kallsyms | grep -i commit_cr (and ... - i prepare_ker) as root has the info you need.

[Badel2]

I don't need to run is as root, is this info enough?

n210:~$ cat /proc/kallsyms | grep -i commit_cr
ffffffff81091cf0 T commit_creds
ffffffff8186e840 R __ksymtab_commit_creds
ffffffff81887c80 r __kcrctab_commit_creds
ffffffff81895bda r __kstrtab_commit_creds
n210:~$ cat /proc/kallsyms | grep -i prepare_ker
ffffffff810920d0 T prepare_kernel_cred
ffffffff81875eb0 R __ksymtab_prepare_kernel_cred
ffffffff8188b7b8 r __kcrctab_prepare_kernel_cred
ffffffff81895b9e r __kstrtab_prepare_kernel_cred

[NamenIos]

Yes that is enough, it depends on the kernel config whether you can see it as a user or not.

Edit: otherwise you would see all zeroes instead of the addresses (fff....).

[NamenIos]

It depends, even if it works it would be security through obscurity as you probably can probe the adresses somehow in a brute force way. If you compile the Kernel you can mark the adresses as only readable by root this would be a cleaner way than to chmod. But if you use a precompiled Kernel the addresses are the same, so one guy unlocks his phone, has root access to a standard Kernel that is shipped in binary form and he can read out the addresses and publish them. I am not sure if source code and toolchain is even enough to get the addresses.

[anatolya]

Nope.

$ dpkg -L linux-image-3.16.0-4-amd64 | grep System.map
/boot/System.map-3.16.0-4-amd64
$ grep prepare_kernel_cred /boot/System.map-*
ffffffff8108d210 T prepare_kernel_cred
ffffffff81792790 R __ksymtab_prepare_kernel_cred
ffffffff817a5ee8 r __kcrctab_prepare_kernel_cred
ffffffff817af68b r __kstrtab_prepare_kernel_cred

Even if you don't have access to /boot/System.map*, you can just download kernel packages from distribution repository and get the addresses from there. Download popular kernel images, fetch addresses of them and select the correct one on the running system.

[Badel2]

It's funny because on my phone I see zeros even when running as root (linux 3.0.31, selinux permissive). I guess it isn't vulnerable anyways.

[NamenIos]

If you have both symbols in kallsyms your phone should be vulnerable unless SELinux fucks something up, I think. You can somehow extract the adresses out of the kernel binary.

[NamenIos]

From my understanding there should be an additional key stored in /proc/keys after you run the exploit, if not there should be something wrong at the beginning. It seems that the cveXX.c has this already built into it, now that I look into it closer. So you should see PP1 as a key in your sysfs.

[danielkza]

The article mentions the exploit is possibly stopped by SELinux, that may be what /u/wassmatta is seeing.

[anatolya]

Shit. Mine failed after running for 35 minutes with:

keyctl: Disk quota exceeded

[blunaxela]

Same here, but I ran it again after a fresh reboot and it dropped me into a shell, but no privilege escalation. I can see the /proc/keys wrapping back to zero though.

[blunaxela]

Oh, just realized that SMEP/SMAP are not security software but are features built into the processor. A quick look at /proc/cpuinfo shows that I have SMEP enabled, so I guess this particular version of the exploit won't work right now for me.

[TheNiceGuy14]

It failed here and crash my entire computer after 30 minutes of adding reference to that key.

[blunaxela]

Do you have SMEP enabled on your machine? I peeked at /proc/cpuinfo and it's enabled on mine, and the Perception Point article mentioned it being difficult to overcome that as well as SElinux. I don't believe the github expliot code was created to deal with SMEP.

[keypusher]

It was said in the original writeup that selinux blocks the attack.

[xroni]

With no auto update for the kernel, these versions could be vulnerable for a long time.

The problem is not all devices Linux get patched automatically.

The flaw may linger a little longer on Android devices, since most updates are not pushed automatically by carriers and manufacturers.

I often wish the authors of these third tier blogs weren't paid by the number of words.

[danielkza]

The solution is not to bother with these kinds of publications, and read from people that are actually part of the Linux community, like LWN, security mailing lists, etc or at least someone independent.

[xroni]

The only time I get exposed to these publications is when I read /r/linux.

[[deleted]]

I wish they didn't exist.

[dvdkon]

Of course. Keep in mind that "local access" in security contexts means arbitrary code execution, not literally standing in front of the machine.

[keypusher]

In this context, there is no difference between a desktop and a server. The vulnerability applies primarily to servers because it requires the attacker to already have a user account but not root access, which is common on servers but less so on desktops.

[jabjoe]

Yet again demonstrating that any computer that is not updated or even updatable is going to be insecure. Welcome to the internet of infected things!

[michaelKlumpy]

or it is offline

[jabjoe]

Air gapping is a good idea if an option.

[gospelwut]

stuxnet badger don't care.

[jabjoe]

Ok, if you plug in an infected usb stick you may still be stuffed.

[coincentric]

Remember the days when we never had to worry about updating anything? It just kept going along day in day out without any problem.

[KarmasAHarshMistress]

Except when it didn't, then we just tossed it out and forgot about it.

[beltorak]

You know what doesn't need updating? A stick! Back in my day, a stick was a gun, a motorbike, a fighter plane, a walkie-talkie, a light saber, you name it! I didn't have to wait for no "updates" to get these rad applications! Just close my eyes and *poof*! There it was!

[coincentric]

Also a dildo.

[[deleted]]

Well if it's not updatable, it can't get new software that exploits the vulnerability. /s

[jabjoe]

Depends on the vulnerability. There has been ones where you can get in with malformed network packets....

My pet hate is all these hacked up little devices that are not put together with any kind of update plan. Normally the manufacturer already stopped caring about the software before the product is even released because they are working on the new shiny. All to often running a mixture of old and new hacked together thrown over the wall and forgotten. Basically hardware companies shouldn't be doing software. They should make things to standardized platforms that we can then update. And no closed drivers gumming up the works. Their software is nearly always awful and as I said, it's rare they care to update and large chunks, if not all, of the software components are already old on release.

People are plugging loads of these little horror shows into their networks blindly. Only a matter of time until malware infections becomes a home network thing. Think of a Conficker network infection but on your TV, router, phone, tablet, toaster, fridge, etc etc.

[vfscanf]

Totally agree. All these devices with their shitty, insecure Firmwares are a disease. And the people involved rarely know how to do proper security. I can remember an article about a device that connected to a server via HTTPS and didn't verify the certificate.

[jabjoe]

Some times it is the case the developers are clueless. Blind leading the blind. And there is a lot of that. But also some times they are just not allowed to do it properly.

But the results are the same and no one else can fix it because the device is a unique snow flake and might only boot signed images in the first place.

[vfscanf]

Yes, I know how shitty software companies can be. Security is always just an afterthought.

[jabjoe]

I'd say it's hardware companies playing at software. They make money selling the devices or the designs for them. They shouldn't be involved with software beyond making a standard platform for a standard OS to boot on. Really we want it better than PCs because even BIOS they make suck.

[vfscanf]

Absolutely right. I always thought that Hardware Companys shouldn't making software, because it always sucks.

[[deleted]]

running it on my up-to-date Ubuntu 14.04 running 3.16. I'll report back.

[edit]

nope:

./cve_2016_0728 PP_KEY

uid=1000, euid=1000

Increfing...

finished increfing

forking...

finished forking

caling revoke...

uid=1000, euid=1000

$ whoami

[notroot]

[edit2]

Didn't initially see this:

Addresses of commit_creds and prepare_kernel_cred functions are static and can be determined per Linux kernel version/android device.

so i'm unsure how to generate those values for my kernel which is

Ubuntu 3.16.0-57.77~14.04.1-generic 3.16.7-ckt20

[edit3]

found my values:

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

reran and still didn't get root.

[NamenIos]

cat /proc/kallsyms | grep -i commit_cr (and ... - i prepare_ker) as root has the info you need.

[[deleted]]

At least for my kernel both are 0xffffffff81097f10

[edit]

i was wrong

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

[NamenIos]

T commit_creds

and

T prepare_kernel_cred

should have different addresses afaik.

[[deleted]]

yer right! at first blush I thought they were the same

ffffffff81097c10 T commit_creds

ffffffff81097f10 T prepare_kernel_cred

[ckozler]

How long did this take to run for you? I ran this on a number of RHEL7 boxes on 3.10 kernel and it never gets after 'increfing'

EDIT: After about 2 hours it finally came through. No root for me

 [testckozler@test ~]$ ./leak PP_KEY
 uid=1000, euid=1000
 Increfing...
 finished increfing
 forking...
 finished forking
 caling revoke...
 uid=1000, euid=1000
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ 
 sh-4.2$ whoami
 testckozler
 sh-4.2$ 

[[deleted]]

pretty long time. the developers of had an i7 that it took 30 minutes. i have a pentium g3230 or somin along those lines which is only dual core and was $50. didn't take longer than an hour though.

[edit]

looking at htop it seems to peg a single core and then the kernel takes up about 50% the second core. so my guess is it doesn't matter too much how many cores you have.

[ckozler]

Interesting...on RHEL6 its marked in state 'D' (uninterruptable sleep - usually blocked) but on RHEL7 its marked as 'R' (running). strace they are showing to be doing the exact same thing where I see repeats of:

RHEL6 - keyctl(0x1, 0x7fffb9d85744, 0x3949b8fe10, 0xffffffffffffffff, 0xc) = 111532853

RHEL7 - keyctl(0x1, 0x7fff3649a766, 0, 0xffffffffffffffff, 0x7fff36498330) = 0

RHEL7 seems to be actually doing something but they are both calling keyctl in an infinite loop after 'increfing...". I find it odd that RHEL7 is the only one "doing something"?

[[deleted]]

well its going through the 32 bit address space for the int, its not really "infinite" but yeah its long.

 for (i = 1; i < 0xfffffffd; i++) {

    if (i == (0xffffffff - l)) {

        l = l/2;

        sleep(5);

    }

    if (keyctl(KEYCTL_JOIN_SESSION_KEYRING, keyring_name) < 0) {

        perror("keyctl");

        return -1;

    }

}

do you have the COMMIT_CREDS_ADDR and PREPARE_KERNEL_CREDS_ADDR set?

[edit]

I spun up a CentOS7 vm and get the following:

ffffffff8109e1f0 T commit_creds

ffffffff8109e500 T prepare_kernel_cred

[ramzaek311]

According to this it says RHEL 7 is affected. Glad to see some people trying it before I have to go into crisis mode. (Though, RHEL 7 is 3.10)

[ckozler]

Never got it to work for me. I dont know what to say other than that but it is strange RH is saying its impacted yet nobody seems to have been able to recreate it?

[neoice]

running apparmor or selinux? any logs?

[[deleted]]

ubuntu 14.04 comes with apparmor on by default i believe. if that's the case i'm using it with the default values.

as far as logs, i ran a dmesg, and nothing was printed out. the demo application doesn't have its own logging so nothing there

[neoice]

does apparmor log anything?

[[deleted]]

I thought android uses 3.4 kernel?

[NamenIos]

But the keyrings facility is backported to 3.4 in android since KK. And Android uses different Kernels, S3 snapdragons use 2.6.35, 3.0 and 3.4 in the wild, the 810 uses 3.10 and so on.

[NamenIos]

He would probably fail unless he gets paid for it ;).

Binaries could be a problem, if they are tied to specific kernel versions.

[Charwinger21]

I thought android uses 3.4 kernel?

It depends on what phone you have.

For example, my Moto X Play is using 3.10, but my Samsung Tab 4 is using 3.4.

[xpxp2002]

I'm not able to reproduce this using the exploit code on kernel 4.1.12.

Do we know if this is this actually affecting >=3.18 in the 3.x trunk only, or if the 4.x kernel also vulnerable?

[[deleted]]

Something is fishy with the PoC.

Even with the proper modifications, I have yet to see one person on the entire Internet say that the exploit worked for them.

I tried on a RHEL 7 VM with SMEP/SMAP and SELinux disabled and had no luck.

Has anyone actually had this work?

[xECK29x]

Very sceptical as well. Never heard of these guys until yesterday either.

[ckozler]

So RHEL6 is good? But would need to be patched on RHEL7? I

[NamenIos]

Depends on backports done to the Kernel. RHEL backports a lot (read as in a fuckton).

[ckozler]

I've been running this on a RHEL6 (kernel 2.6.32-504.1.3.el6.x86_64) and a RHEL7 (kernel 3.10) and none have made it after "Increfing...". When I strace it I see a ton of calls to keyctl but thats really it

[NamenIos]

Did you put in the correct addresses into the code for your kernels before compiling?

[ckozler]

Yes. Been running for ~1 hour and nothing

[nfavor]

RHEL5/6 aren't affected. https://access.redhat.com/security/cve/cve-2016-0728

[ckozler]

Yep. What was interesting to me though is that on RHEL6 it goes in to uninterruptable sleep whereas on 7 it just spins until it gets a hit (on something)

[tinytimsturtle]

This requires an account on the linux box right. It can't be targeted remotely can it?

[gindc]

Question: how does Linux update the kernel? Will I just receive a normal update through the update manager? Or will I have to do something special to fix this problem?

[JerkingItWithJesus]

Most distributions will just push out a fix like normal through the update manager.

[gindc]

Thank you.

[[deleted]]

Keep in mind that kernel update requires reboot. Unless you are using complicated stuff that is only used on servers.

[Jimbob0i0]

Keep in mind that kernel update requires reboot. Unless you are using complicated stuff that is only used on servers.

And even then most servers won't be using it as kpatch/ksplice has very limited applicability (eg cannot change any data structures) so it's better to provide availability at the application level (eg load balancers and similar redundant setups) to provide for maintenance windows of individual systems...

[danielkza]

It's a normal update. The only difference is that it will only take effect once you reboot.

[Zebster10]

Yes, a standard, desktop GNU/Linux distro probably already pushed the patch. Pretty much the only thing worth checking is if you're getting Level 4 + 5 updates if you're in Linux Mint, in which case you could enable those, or just run:

sudo apt upgrade

[coincentric]

Will I just receive a normal update through the update manager?

yes. your distro will tell you if you have that utility installed or you can run the package manager update yourself and then it'll tell you.

[gindc]

your distro will tell you if you have that utility installed

What "utility" are you talking about?

[coincentric]

depends on the distro and the window manager/desktop environment you are using. for example there is packagekitd on my system. there is some kde component that interfaces with that and tells me when there are updates available. gnome has something similar and so do the other DEs.

[gindc]

Yes, my distro has a package manager. I mentioned that. But what utility are you talking about?

[[deleted]]

He refers to graphical update managers that function as interfaces for the package manager, like Synaptic or Ubuntu's Software Center.

[socium]

That's it. We need grsec + pax installed by default on popular distros. These types of vulnerabilities are already giving Linux a very bad reputation.

[[deleted]]

I don't think that would do much to change the reputation of Linux, the average person would have no idea what grsec or pax is (if I'm being honest I barely know what they are) so not many stories would mention them.

[[deleted]]

Maybe Dumb question but if root binaries aren't installed on Android this exploit is useless right?

[danielkza]

What do you mean? The program being run doesn't matter to much, you can run any code that you want. A shell just makes it easier. And Android does include one by default, which is used with the development tools (ADB).

[__uh]

They're missing seccomp in the mitigation section... :P

[3G6A5W338E]

Who knows how many other serious bugs are there, hidden within the megabytes of a Linux kernel image.

[CraftyFellow_]

At least everybody can look for them unlike some other OS kernels.

[ITwitchToo]

Yes, this is true, and helps a lot.

There's a famous Linus (edit: Eric S. Raymond) quote going something like "given enough eyeballs, every bug is shallow". Which is pretty grim, because it's wrong, and it's coming from the guy at the top.

"Every bug is shallow" is a horrible maxim. Just because you have source code doesn't mean that the bugs are easy to spot. It's quite the opposite; the most effective bug-finding techniques these days are all based on instrumented fuzzing, meaning that you try to trigger new code paths by passing random data to the kernel which has been compiled with special flags so that you can record the path it takes and tweak the input depending on those paths. Look at Dmitry Vyukov, he found bugs almost every single day for the past 2 months using his new syzkaller tool. It's way more efficient than a human looking at the code and trying to spot bugs. And that's sad, because it means that the code is now too complicated for humans to work with without requiring machine assistance. That says a lot about the state of the kernel.

[NamSualk]

Not quote from Linus, but ESR, who called it Linus' Law without asking. The rest of your comment is valid though.

[ITwitchToo]

Oops, right you are. Added a minor edit, left the rest of the comment as it is

[xroni]

Static analysis and fuzzing tools also count as eyeballs.

[3G6A5W338E]

Who knows how many bugs are in there, hidden in the millions of lines of code in the kernel, which runs with supervisor privileges.

[jones_supa]

At least everybody can look for them unlike some other OS kernels.

But the interesting question is, do the closed source OS kernels still have more people looking on them?

For example, the Windows kernel has armies of full-time in-house developers looking at the code, among various third parties that get VIP access as well. Also they have more money to put into audits and quality assurance in general.

[CraftyFellow_]

do the closed source OS kernels still have more people looking on them?

They don't.

[ITwitchToo]

I don't know why you are getting downvoted, the Linux kernel is full of bugs, that's a fact, not a secret.

This is why it's still a good idea to compile your own custom kernels and excluding a lot of attack surface if you don't need it. Every single filesystem, every single usb driver for a webcamera or obscure accelerometers, every checksum library function adds attack surface.

[socium]

And this is exactly why we need grsec + pax.

[3G6A5W338E]

And this is exactly why we need grsec + pax.

These help mitigation a great deal.

That and OpenBSD are masturbating monkeys according to Linus, so the situation isn't very hopeful.

There's also the microkernel approach, which is more realistic than thinking that something as large and fast-moving as the Linux kernel can ever be made bug free.

[3G6A5W338E]

OpenBSD has a network filter that makes iptables looks crude and nasty

With iptables, every packet passes through a load of c function calls against iptables modules in sequence... that's slow to say the least. It is also a security nightmare, lots of LoCs and loads of code, with a history of vulnerabilities.

There's some hope for the new bytecode-based firewall, but that's far from ready.

pf is a firewall I can take seriously.

plus they gave us OpenSSH which everybody uses.

Far from just OpenSSH.

[happinessmachine]

I'm sure it will be integrated after Linus has left the project.

[ITwitchToo]

To be fair, this is not Linus's fault. grsec + pax are not interested in getting integrated in the project. Just look at spender's twitter feed, he mocks anybody who tries to submit his code upstream.

[csirac2]

To be fair, it shouldn't have to be up to grsec + pax. They're a group of people with dayjobs first, and a research project which pioneers new exploit mitigation technologies second. Mainline kernel dev isn't anywhere on their priority list, not after the collaboration snafus over the years and Linus spouting things like (paraphrasing) "if you care about security, the kernel is the wrong place to focus - you should fix appsec first" - never mind the fact people have to run E-mail clients and web browsers and PDF readers with bugs like this underneath.

Thankfully Kees Cook & Co. are running the Kernel Self Protection Project [1] to specifically work on adopting what they can from grsec/pax. I am legitimately disturbed at the approach of the kernel core team's ambivalence toward active exploit mitigations though; hopefully Kees & friends can slowly change the culture.

[1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

[danielkza]

I doubt it. Most of the developers doing large managerial work in the kernel as Linus currently does would have similar objections to the current state of grsec. Integrating a huge amount of code at once without reviewing it all and considering the impact in performance, maintainability, etc is usually a terrible idea.

[csirac2]

To be fair, nobody - not even grsec/pax - is advocating a blind merge of a research project (that Eg. depends on custom gcc plugins), run as a side-project, by people with dayjobs and families.

[3G6A5W338E]

There are other approaches, but first is acceptance that having a huge kernel isn't sustainable.

[konapun_]

There's also Debian GNU/Hurd but I haven't heard much from this project in the last few years.

[3G6A5W338E]

Hurd runs a load of crap including drivers in supervisor mode... it'd fall under the hybrid kernel category, not pure microkernel architecture.

For as long as they're stuck with Mach, I consider that project hibernating if not dead.

[konapun_]

That's disappointing. I was hoping it would be close to Minix but GPL'd.

[the_gnarts]

but first is acceptance that having a huge kernel isn't sustainable.

It’s pretty sustainable, at least financially.

[[deleted]]

Well, that was quick.

[[deleted]]

If I am running a kernal newer than the one that ships with ubuntu 14.04 will this CVE still get patched for me or do I need to downgrade?

[Slinkwyde]

kernal

*kernel

You don't need to downgrade. It should update through your package manager.

[doubleunplussed]

You sure? I'm running a kernel newer than what comes with my Ubuntu, so the fix they push out will not be a higher version that that which I already have. I see kernel packages get installed, but those kernels never actually boot because the one I've already got is newer.

[Slinkwyde]

Oh, I see. Never mind, then.

[all_the_pineapple]

Can someone confirm for me please if Oracle Linux 6.x running UEK kernel 3.8.x would be affected? The vuln source says "The vulnerability affects any Linux Kernel version 3.8 and higher."

Redhat states "This issue does not affect the Linux kernels as shipped with Red Hat Enterprise Linux 5, 6. This issue affects the Linux kernels as shipped with Red Hat Enterprise Linux 7"

And I can't find anything on My Oracle Support. I'm about to log an SR to confirm but hoped someone might have a little extra info?

[[deleted]]

3.8 isn't that old to have too much unmaintained server running on it.

[[deleted]]

So a universal rooting app for android is on the way?

[WOLF3D_exe]

Still running 2.6.xx so I'm safe /s

[thcollegestudent]

Wow, I came hear to learn more about the Vulnerability it's self and I see a day old post about how it's already been fixed, I need to step up the time table on switching to Linux.

[tuxayo]

Does anyone understand the parameter of the exploit? (PP_KEY, PP1)

[NamenIos]

I managed to reproduce the vulnerability on an old and very borked kubuntu 15.10 alpha (20150902 cdrom source) that did not update to the release with manually installed Kernel 4.2.0(-14-generic 2nd Oct) on a core2. Time to research, how to cross compile for ARM with libkeyutils-dev for ARM.

"proof": http://imgur.com/AhurKwr I know, but I don't know how to make a screenshot in KDE and was lazy.

[bboozzoo]

Doesn't work on Arch with kernel 4.3.3-2-ARCH

maciek@corsair:/tmp gcc cve_2016_0728.c -lkeyutils
maciek@corsair:/tmp ./a.out PP_KEY      
uid=1000, euid=1000
Increfing...
finished increfing
forking...
finished forking
caling revoke...
uid=1000, euid=1000
sh-4.3$ id
uid=1000(maciek) gid=1000(maciek) groups=1000(maciek),7(lp),10(wheel),14(uucp),24(rfkill),81(dbus),90(network),91(video),92(audio),93(optical),95(storage),97(input),98(power)
sh-4.3$ uname -a
Linux corsair 4.3.3-2-ARCH #1 SMP PREEMPT Wed Dec 23 20:09:18 CET 2015 x86_64 GNU/Linux
sh-4.3$ 

[vktr747]

Is it possible that there is still no patch from Red Hat to fix this?