Linux Kernel Use-After-Free Remote Code Execution Vulnerability

http://www.securityfocus.com/bid/93304/discuss

by DiabloD3 • 10 years ago

97 116 10 years ago

micaksica• 10 years ago

What happened to make this updated? This was patched in March upstream, and it appears it made it into an Android patch release a couple of days ago.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

[2] https://source.android.com/security/bulletin/2016-10-01.html

DiabloD3• 10 years ago

https://source.android.com/security/bulletin/2016-10-01.html...

Better URL that goes right to the appropriate section.

startling3• 10 years ago

It was fixed, but not (publicly) recognized as a security issue, so likely not backported + updated by distros in "stable" channels.

IgorPartola4• 10 years ago

Obligatory comment so nobody else has to: C is a terrible language for security and we must abandon it immediately. Anyone that uses it has clearly not heard of Go/Rust/Haskell. We should just abandon the Linux kernel and start from scratch. And we can unit test the shit out of it to avoid security vulnerabilities. Hasn't Heartbleed taught us anything? MongoDB is web scale. Ron Paul 2012.

qwertyuiop9249• 10 years ago

The sarcasm is strong with this one...

sidlls• 10 years ago

In fairness I haven't seen anyone make a serious comment like yours yet in this thread.

caconym_2• 10 years ago

"in b4 'we should rewrite W in X/Y/Z'" has become the new "we should rewrite W in X/Y/Z".

SFJulie• 10 years ago

kernel security and later mongodb appearing randomly in a comment is like priesthood and pedophilia randomly associated. It stings of irony.

oldmanjay• 10 years ago

The defensive tone of this comment is unseemly. C is just a tool, and I assure you, one that feels nothing for you.

IgorPartola4• 10 years ago

I love me some C. Some of the funniest projects I have worked on have been written in C. My comment was sarcastic.

nine_k3• 10 years ago

Go, unlikely. It's safer but it has other problems. Haskell is great but it's runtime makes it hard (though not impossible) to use in kernel development.

Rust and ATS seem to be pretty well suited. With Rust getting more and more traction, maybe not all is lost :)

smsm423• 10 years ago

I have extremely hard time believing there can be a viable OS kernel project on Haskell. I mean, yeah, you probably can write OS kernel in Haskell, if you are determined enough. But I don't believe you can make it into a viable project. Rust - maybe, if you can get enough mindshare. Which is also a big if so far...

drvdevd4• 10 years ago

I played around with getting a Rust kernel module to work before. And I eventually got a "hello world" in my dmesg. But what I realized in so doing was that seemingly 90% of the higher level features of Rust were lost to my module -- essentially I got the language memory security features (borrowing and ownership) but with very little standard library help, which made the whole endeavour seem much less practical still than just using C and libc (because I would have to reimplement a lot of that functionality in Rust -- Kernel Rust, if you will).

I think if the Rust communtiy wants to make it somehow to the Linux (or other UNIX or windows) Kernel space, there needs to be an effort to build Kernel Rust, if there isn't one already..

imglorp• 10 years ago

Why does ATS not get more traction in discussions like this? That's what it's made for. This is the only mention so far in this comment page.

kardashian0074• 10 years ago

Seriously, two things: formal verification of correctness is sorely needed and a language platform which has complete, bidirectional C interoperability in targeting both kernel- and user-land which can be gradually migrated to one compilation unit a time and has much more safety, is more succinct, has C feature parity and no/minimal runtime performance hit would be requirements for candidates to change languages, but only after impressing Linus, lieutenants and contributors of undeniable value.

See also: seL4, Isabelle/Coq, Idris

zzzcpan4• 10 years ago

I disagree. It is possible to put some real effort into the compiler making the same C code safe against such problems without infinitely expensive rewrites.

moosingin3space• 10 years ago

seL4 looks like a great base to build secure embedded systems on. There's an interesting project called robigalia that aims to make it possible to build seL4 userspace threads in Rust, which should be an excellent base to build on.

olalonde• 10 years ago

You had me until "MongoDB".

notalaser• 10 years ago

To be fair, there are a lot of places in the Linux kernel where primitive storage methods are used. In USB drivers, Vendor ID - Product ID pairs are stored in arrays. It's terrible and, most important, it doesn't scale. Being able to SELECT on a given VID would be really useful -- and it's really cool that MongoDB doesn't really impose too many constraints on the structure of your data.

Look, this hasn't been a good day so far, okay?

Hydraulix989• 10 years ago

If anything, security vulnerabilities are precisely the kind of bugs that easily sneak by unit tests.

drvdevd4• 10 years ago

I propose a new name: a dijkstranbug. Kinda like a heisenbug except specifically for unit tests.

IgorPartola4• 10 years ago

Try reading my comment in the most sarcastic tone you can manage.

Unit testing for security vulnerabilities has been discussed to death on HN and is generally agreed that it doesn't work. Yet, every time there is any kind of vulnerability, a comment like mine shows up, except in ernest.

qwertyuiop9249• 10 years ago

No. Stop it. I don't want to hear that we should be re-writing all of our systems code in Rust, or that Oberon and the Wirth family should have won, or that C is crap, and Linux should die, and be re-written, or that this wouldn't have happened if we had all just adopted the Lisp Machine.

We've all heard it already, we all know what you'll say. So skip the smug post, and go do something productive. Like writing a really cool piece of new code, or fixing a use-after-free, or posting something more insightful, or inventing a new type of shoelace that doesn't come untied until you want it to.

nine_k3• 10 years ago

Instead of fixing a particular use-after-free, how about making use-after-free impossible?

walter_bishop• 10 years ago

Instead of fixing a particular use-after-free, how about making use-after-free impossible?

Yes ..

Does this vulnerability work only on a particular architecture?

otterley• 10 years ago

At what cost to performance? Very rarely are there solutions that exist without tradeoffs.

qwertyuiop9249• 10 years ago

Great. Instead of telling us, most of whom already know, about it, go do it.

kardashian0074• 10 years ago

There are no unicorn solutions, however being religously blind to potential net value of fallible but potentially better interoperable alternatives would be irrational. Any rewrite cannot likely be accomplished in one pass (without some really smart code transpiler), but would more likely occur on a gradual migration todo list with a bidirectional interoperable language. The evaluation of such languages would likely involve requesting necessary features such as freestanding compilation, performance profiling/tracing tools and debugger integration, proofs of correctness and GC-less operation, among others. It's not impossible but it would need to be demonstrated that the perceived immense cost is significantly offset by the perceived immense value over "doing things as they've always been done."

swsieber• 10 years ago

And it definitely could be done in one pass because bugs like this do exist, and the language we want to port to should prevent them.

geofft3• 10 years ago

The smug replies on this comment seem to be the ones saying "Don't tell me about Rust".

So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? I've been a C++ and C developer for a long time and have been waiting for some safer language that lets me do what I've been doing in those languages. Knowing that Rust was a realistic option was what inspired me to learn it and write new things in it. If that happens at scale, that's how we actually get things written in a memory-safe language.

sirtaj• 10 years ago

So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive?

The Linux kernel didn't get written because people on a forum said "we need to write a complete open source reimplementation of the UNIX kernel," but because Torvalds just went ahead and wrote it. Most things in F/OSS work that way.

falcolas5• 10 years ago

If it hasn't happened already, with another of the dozens of memory safe languages (like ada) which have been on the market for dozens of years, another memory safe language coming (like Rust) along won't change that.

xenadu02• 10 years ago

"The revolution will not be televised".

The beginning of the end of use-after-free, buffer overflows, stack smashers, et al will be when we as a community finally accept that C is a terrible language, impossible for ordinary humans to reason about, and must be abandoned. Only when we begin to accept that truth will we all get serious about moving away from it.

For many years the response has been that "C is fine" or some variant of "humans will be better programmers in the future" both of which are demonstrably false.

No one questions the wisdom of paramtaraizing SQL. No one questions the wisdom of not writing your own crypto. Yet despite the mountains of evidence, wasting billions (yes BILLIONS) of man-hours and dollars, and even lives lost there is still resistance to the idea that C needs to die ASAP.

So as long as there are posts like yours our job of educating and persuading isn't finished and that's extremely important if we have a hope of actually making this desperately needed change.

If you still doubt let me go ahead and make a prediction: before the end of the year there will be another RCE exploit in the Linux kernel discovered and a different one will be written, code-reviewed, and committed but not discovered until later (but within 5 years). I'm happy to put $1,000 on this wager.

crististm• 10 years ago

Actually, it is still possible to use C as a higher than assembly target language for compilers.

qwertyuiop9249• 10 years ago

I've got no problem admitting that C isn't good enough in most cases, and should probably die. I know that's true. I'm just sick of the annoyingly smug comments about it that pop up like mushrooms on HN. If you're posting here, you're more often than not preaching to the choir.

GrumpyYoungMan• 10 years ago

The beginning of the end of use-after-free, buffer overflows, stack smashers, et al will be when we as a community finally accept that C is a terrible language, impossible for ordinary humans to reason about, and must be abandoned.

1) All the complaints you have apply equally well to assembly language, yet assembly language is all that the CPU understands. Somebody always has to deal with the low level complexity of writing the foundational software constructs necessary to build safe environments and C is still the most natural mapping to varied assembly languages that we have.

2) Nothing else will fit for many embedded systems. Your choices are C or assembly language. What safe environment/language are you going to fit into a microcontroller with 1kB of RAM?

(And, yes, maybe Rust or one of the other proposed system language replacements will be better than C someday, but that someday isn't today.)

topspin• 10 years ago

Well that's the thing about C and its ilk; it is an endless wellspring of awful failures and so the voices you are trying to shout down have an unlimited supply of ammo. This will keep happening and you're going to keep hearing about it and the arguments for alternatives will continue to strengthen. That's the reality to which you need to adapt, if you're a reasonable person.

The advocates of these alternatives aren't creating this situation. The unavoidable fact is that our traditional tools have a propensity to propagate bugs that are fabulously difficult to discover. That's one of the lessons of nearly a half century of C. New tools are emerging that solve this problem and their advocates have every reason to say so.

Another lesson C teaches us through its popularity and longevity is that performance will always be critical for systems code; there will never be a day when we can squander cycles and RAM on garbage collectors and reference counts and indirections and all the other bookkeeping and abstractions inherent to so many languages that have utterly failed to displace C for systems programming.

I don't know what the future looks like. Maybe it's Rust. Maybe Linus will get fed up and invent a better language in 4 days. Maybe someone will create an AI system that can spot this sort of bug before it ever gets checked in. All I know for sure is that the current situation is intolerable and yelling at people to shut up about it won't work.

zigzigzag• 10 years ago

I don't know about that - very little software is written in C these days. Even parts of the Windows and Mac kernels are written in at least C++ and Microsoft had an entire OS written in C# internally. Meanwhile the games industry has been C++ since forever (which still isn't great but better than C) and most business and web software is written in GCd languages.

BTW the kernel is full of reference counts.

qwertyuiop9249• 10 years ago

I'm fine with admitting C had flaws. It does need to be replaced for many projects. It's just the smug comments on HN that irritate me, especially because most of us are already in agreement (including me, now), and those who aren't won't be convinced by the sheer power of smugness. In short, I'm not complaining because the people who do this sort of thing are wrong, but because they're not actually helping.

lmm• 10 years ago

This is a discussion forum, of course you're going to find talking rather than doing here.

Once there's a firm consensus that it's time to move away from C we'll probably stop talking about it. But that consensus has to develop through discussion and argument here and elsewhere (and if you look at the conversations now compared to a year or two ago, I'd say we've made a lot of progress). If you don't believe there's value in talking about technical issues then what are you even doing here?

meanduck• 10 years ago

I guess GP is refering to repetitiveness of same arguments.

A tree thread is good for discovery but not so good for reaching a conclusion/consensus. Flat/linear thread should be used instead.

qwertyuiop9249• 10 years ago

There's actually a pretty solid consensus here. I'm the only one I've seen arguing about C, and even I agree that it should be moved away from with these sorts of codebases. It's the rest of the world which doesn't have a consensus.

You're welcome to post, of course. I'd just rather you not. There's no sense preaching to the choir.

falcolas5• 10 years ago

I'll add to this. Before you can even begin championing your language for kernel development, make sure it can compile to all of the same architectures that C can. Make sure that programs written in your language are as space and time efficient as the equivalent C programs. These are things you can do today, if you feel strongly enough about this cause.

Once your language is at that point, then start building up your arguments to convince Linus and the majority of the core kernel developers that your language is the right choice for continued development.

Until these occur, it's all just pointless speculation.

zzzcpan4• 10 years ago

to convince Linus and the majority of the core kernel developers

The biggest cost is not them, it's every other C programmer, every other company, the whole industry. It's unrealistic to even think that any significant part of them is going to invest resources into another language just to gain memory safety.

Animats• 10 years ago

Isn't the Linux kernel tested with a zeroing storage allocator?

caf3• 10 years ago

Yes (actually, a poisoning allocator which is the moral equivalent).

This bug was found because a KASAN ( https://www.kernel.org/doc/Documentation/kasan.txt ) assertion triggered during fuzzing.

mkj2• 10 years ago

What circumstances are needed for this to be exploitable? Wondering if iptables could mitigate for systems where upgrading the kernel is non-trivial.

zzzcpan4• 10 years ago

Haven't looked at this too closely, but iptables are unlikely to help. The bug appears to be in the recvmmsg() syscall, which is where the packet leaves the kernel and enters the userspace. The syscall itself is not that widely used, only for some unusually optimized UDP servers, you are unlikely to have one running. But you can check with strace just to be sure.

mkj2• 10 years ago

Yep. Though I assume this needs some interesting network traffic to trigger it.

caf3• 10 years ago

https://codesearch.debian.net/search?q=[^_]recvmmsg\%28[^\%2...

(Many of the results are for code like language runtimes and debugging tools that don't actually use recvmmsg() themselves)

startling3• 10 years ago

I wrote a bit about it: https://blog.lizzie.io/notes-about-cve-2016-7117.html

tl;dr looks like it'd function well a local privilege exploit. not an expert, but as a remote exploit think it would need 1) a service running recvmmsg (which is kind of unlikely) 2) a way to cause recvmsg to error, and 3) a way to cause the service to close its socket in the middle of the recvmmsg call.

vzcx• 10 years ago

Nice writeup!

I was just starting to look into this since people were claiming it was pretty severe and yet I hadn't seen any POC's. Have you made any more progress?

For whatever my opinion is worth (i.e. not much), I would agree with you that remote exploitation of this particular bug would be really difficult.

astrodust• 10 years ago

So what can one do about this? What amount of panic is appropriate?

kardashian0074• 10 years ago

Delpoyed boxes: ksplice / kpatch or run updates when available.

And consider mitigations at various tech stack layers.

AstralStorm3• 10 years ago

I haven't found a way to patch a kernel with nontrivial modules without kernel restart. This makes the mechanism only useful to reduce system reboot times after a patch.

TheDong• 10 years ago

EDIT: do not panic as much, nvm, this is in `recvmmsg` not `recvmsg`, which is not used by much software. Definitely not sshd or nginx. I can't find any software I have installed that does.

I think the best advice is not to listen to anyone on HN about this shit except for cperciva

Original response:

----

Reimage everything from scratch if you're a bit paranoid, because in theory someone could have rooted every server running any internet-accessible thing (even just sshd or nginx)

Realistically, update ASAP and figure out from other sources how difficult this is to exploit and how likely it is that anyone actually did get a working RCE

bitzun• 10 years ago

Can anyone post some of the details here or provide another link that has more details than The Register? securityfocus isn't loading for me.

startling3• 10 years ago

I couldn't find anything, so I wrote some https://blog.lizzie.io/notes-about-cve-2016-7117.html

sargun• 10 years ago

Website seems to be down. For those that are curious, it's CVE-2016-7117.

Mitre link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7117

caf3• 10 years ago

The commit for the fix is more interesting.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

HerrMonnezza2• 10 years ago

At the moment, the link you posted says "This candidate has been reserved by an organization or individual that will use it when announcing a new security problem."

I guess the post on securityfocus (also not reachable) slipped out before end of embargo time?

fulafel2• 10 years ago

Here's my attempt at a constructive idea, inspired by all the preemptive C comments:

The l-k devs and the big commercial Linux vendors/users (Google, IBM, Red Hat, Amazon etc) should gang up and start offering big bounties for these. And simultaenously start doing subsystem rewrites in a memory-safe way prioritized by bugs found by bounty program (and other ways). If they're allergic to non-C languages, a safe C subset like SAFEcode or C0 could be used[1].

[1] I'm saying it's possible to have a memory safe C subset with current compiler technology, even though you can point out something missing from C0

pawadu• 10 years ago

Google already pays bounty for a lot of FOSS projects.

And if the bugs you find can be exploited in google products the bounty is _very_ high.

sn• 10 years ago

This functionality appears to have been introduced in linux 2.6.33 with commit a2e272554 .

Looking at http://vault.centos.org/6.8/updates/Source/SPackages/kernel-... it looks like RedHat backported this function but has not applied the fix.

kopy• 10 years ago

I don't get it, if this was fixed in March, which systems are compromised by this?

Do I need to worry about a fully upgraded ubuntu 14.04 with or without the Hardware Enablement Stack?

fulafel2• 10 years ago

Due to the way Linux people handle security fixes, a lot of the time the code fix goes in at first, then people decide it's an exploitable vulnerability, and then they have an embargo period without public discussion so everyone[1] can release a security patch at the same time. So hopefully Ubuntu has a kernel update ready to be released and they will send it out just about now.

Unfortunately in this case Ubuntu's CVE tracker just shows "needs-triage" or "does not exist" for CVE-2016-7117.

[1] Well, most Linux systems don't get timely security patches, like most Android phones or most embedded/iot products, but you get the idea

anarcat• 10 years ago

for those wondering, Debian is mostly not vulnerable, except for the oldstable/LTS release:

https://security-tracker.debian.org/tracker/CVE-2016-7117

solarized• 10 years ago

Just wait until torvalds wrote a new language. Publish it and made it as a new standard. Again.

bArray• 10 years ago

Programmers, hear me! It is true, what many of you have heard. The security experts have gathered an army and as I speak, that army is drawing nearer to our kernel.

Believe me when I say we have a difficult time ahead of us. But if we are to be prepared for it, we must first shed our fear of it. I stand here, before you now, truthfully unafraid. Why? Because I believe something you do not? No, I stand here without fear because I remember. I remember that I am here not because of the path that lies before me but because of the path that lies behind me. I remember that for many years we have fought these security guys. I remember that for many years they have sent their armies to destroy us, and after a life-time of war I remember that which matters most... C is still here! Today, let us send a message to that army. Tonight, let us shake this thread. Tonight, let us tremble these keyboards of silicon, steel, and plastic, let us be heard from low-level assembly to bloat-ware web applications. Tonight, let us make them remember, THIS IS LINUX AND WE ARE NOT AFRAID!

HerrMonnezza2• 10 years ago

It seems that Linux distros are now releasing fixes:

- Debian is prevalently not vulnerable: https://security-tracker.debian.org/tracker/CVE-2016-7117 (except the "oldstable" release)

- for Ubuntu, the situation is more complicated, as it depends on the actual kernel package installed: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2... For the "linux" kernel package (prob the most common), the situation looks like this at the moment::

        Upstream:	released (4.6~rc1)
        Ubuntu 12.04 LTS (Precise Pangolin):	needed
        Ubuntu 14.04 LTS (Trusty Tahr):	released (3.13.0-86.130)
        Ubuntu Touch 15.04:	DNE
        Ubuntu Core 15.04:	pending (3.19.0-59.65)
        Ubuntu 16.04 LTS (Xenial Xerus):	released (4.4.0-22.39)
        Ubuntu 16.10 (Yakkety Yak):	not-affected (4.4.0-22.39)

- for CentOS/RHEL, my understanding is that fixed kernels have not yet been released: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7117

Linux Kernel Use-After-Free Remote Code Execution Vulnerability

Related Stories