
Linux Kernel Use-After-Free Remote Code Execution Vulnerability - DiabloD3
http://www.securityfocus.com/bid/93304/discuss
======
micaksica
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...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d)

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

~~~
DiabloD3
[https://source.android.com/security/bulletin/2016-10-01.html...](https://source.android.com/security/bulletin/2016-10-01.html#remote-
code-execution-vulnerability-in-kernel-networking-subsystem)

Better URL that goes right to the appropriate section.

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

~~~
xenadu02
"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
Actually, it is still possible to use C as a higher than assembly target
language for compilers.

~~~
MaulingMonkey
While I'm really interested in this for making languages available everywhere
(tm), basic things like signed integer overflow being undefined behavior make
me question is C is fit for purpose even here.

~~~
jjnoakes
Since you are generating the C code, you can generate the appropriate checks
where needed to avoid such undefined behavior too.

~~~
MaulingMonkey
Which is the one thing keeping it in the running.

The problem is this line of reasoning doesn't generally hold up when applied
to C codebases (because in practice statistics catches up with you eventually)
and C code generators, in effect, happen to contain an admittedly small but
rather obfuscated C codebase.

Moreover, you must always include such checks - manually crashing on e.g. null
pointers even if you'd be entirely satisfied with a segfault - just to avoid
the optimizer potentially going apeshit on your code. Which can have... poor
effects on program performance.

~~~
jjnoakes
If you are writing a code generator, it all depends on the source language.
If, for example, your source language doesn't have NULL pointers, then you
don't have to waste cycles checking them in C.

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

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

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

~~~
caf
[https://codesearch.debian.net/search?q=[^_]recvmmsg\%28[^\%2...](https://codesearch.debian.net/search?q=\[^_\]recvmmsg\\%28\[^\\%29\]&perpkg=1&page=1)

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

~~~
ajb
Ouch, it's in chromium though.

------
sargun
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](https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-7117)

~~~
caf
The commit for the fix is more interesting.

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d)

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

~~~
caf
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](https://www.kernel.org/doc/Documentation/kasan.txt)
) assertion triggered during fuzzing.

------
sn
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-...](http://vault.centos.org/6.8/updates/Source/SPackages/kernel-2.6.32-642.4.2.el6.src.rpm)
it looks like RedHat backported this function but has not applied the fix.

------
kopy
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?

~~~
fulafel
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

------
HerrMonnezza
It seems that Linux distros are now releasing fixes:

\- Debian is prevalently _not_ vulnerable: [https://security-
tracker.debian.org/tracker/CVE-2016-7117](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...](https://people.canonical.com/~ubuntu-
security/cve/2016/CVE-2016-7117.html) 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](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7117)

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

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

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

And consider mitigations at various tech stack layers.

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

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

~~~
nine_k
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 :)

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

~~~
bluejekyll
I think Rust has the mindshare, what it needs is people actually doing it.

Redox is a ground up OS, but I wonder if we shouldn't instead be taking more
of an Oxidization approach where we rewrite more and more pieces of an
existing OS in Rust piecemeal. This would add some overhead (programmatically
not instructionwise) of a lot of context switches though between the C and the
Rust code, which is to say it would be a little ugly for a while.

It might be cleaner to go after a microkernel to do this though, like L4 or
rumprun.

~~~
smsm42
> I think Rust has the mindshare, what it needs is people actually doing it.

That's kind of the opposite of having the mindshare, IMO :) Having the
mindshare means people would be reaching for it when they need things done,
not have to be dragged in, and there's a wide pool of people knowing it.

I'm pretty sure you can write OS kernel in almost any language that can be
compiled into runnable code, and probably if you are really determined also in
those that are compiled into bytecode. As I said, it's not the main issue.

Unless you are a titan of programming that can do an OS project all by
yourself, or have more money than Google, you'll need random people to come to
the project, pick up pieces and work on them. The question is, does Rust have
pool of people wide enough so that probability of people wanting to work on
_your_ project is higher than your needs?

C definitely has a huge pool. So do C++, Java, JS, Python and many other
languages. Rust? I'm not sure it does so far. Maybe I'm wrong.

~~~
bluejekyll
Remember, Rust is just a year old. There are already a few OS projects going
in it. All the languages you mentioned are >10 years old.

I think for its age, the success it already enjoys is impressive.

~~~
smsm42
It's not a criticism of the qualities of Rust. It's just an assessment of the
current state of affairs. Maybe Rust will gain the mindshare in 3 years. We'll
see. I personally think having something better than C but as ubiquitous and
supported as C would be awesome. Is it Rust? We'll see in 5 years.

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

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

------
bArray
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!

