
CVE-2016-2384: arbitrary code execution due to a bug in usb-midi linux driver - xairy
https://xairy.github.io/blog/2016/cve-2016-2384
======
jimrandomh
Short version: A bug in a Linux USB device driver can be caused to take over a
Linux machine by plugging in a malicious USB device. An attacker would either
use a custom USB dongle, or a programmable device with a USB connection such
as a cell phone.

There's a narrow problem here, which is the bug in the device driver. That'll
be fixed of course, now that it's gotten attention. But fixing this bug will
not solve the problem, because there is a truly enormous number of different
USB device drivers, most of which are poorly audited, run in kernel space, and
correspond to unusual hardware. The _real_ problem is that plugging in a
device can cause any obscure device driver to load, without user confirmation.
So for example, someone can plug in a cell phone, and the cell phone can claim
to be an obscure kind of printer that no one has seen since the 90s, and the
system will go ahead and load that device driver.

The solution is to require user confirmation before accepting any USB device
that hasn't been seen before. Just a simple popup: You have connected [type of
device], Ok/Cancel. The only tricky part is input devices like keyboards and
mice, where this could create a chicken-and-egg problem with the confirmation
prompt. (And devices pretending to be keyboards can be dangerous; they can
type commands). Fortunately, there is a solution, albeit one which will take
some programming work: accept keyboard input from keyboards that have either
been confirmed by a prompt _or_ have typed the user's login password. (Since
some "keyboards" are actually things like barcode scanners).

~~~
contingencies
Another solution is to not compile drivers that you don't need, and to take
minimizing kernel attack space as seriously as running a firewall. It should,
in my opinion, be routine to run a reduced kernel in production, however most
of the industry appears to use stock kernels from a few major vendors. The
likes of CoreOS are probably helping here. Keep it up.

~~~
geofft
For a server-ish machine, disabling module autoloading is fairly
straightforward: set /proc/sys/kernel/modprobe to /bin/false. (You can also do
something fancier like
[https://scripts.mit.edu/trac/browser/trunk/server/fedora/con...](https://scripts.mit.edu/trac/browser/trunk/server/fedora/config/etc/scripts/modprobe)
to report what the process is.)

This is also useful to disable modprobing obscure networking protocols just by
an unprivileged process calling socket(SOCK_STREAM, AF_FULLOFBUGS, 0), which
was a fruitful source of exploits at least a few years back.

However, for most server machines, if an attacker can plug a malicious USB
device into your machine, something has already gone very wrong. (And for a
good chunk of servers these days, they don't even have USB because they're
VMs.) The primary threat model for this sort of thing seems to be laptops that
are briefly left unattended and locked, or "Hey, can I charge my phone off
your laptop."

For the unattended-and-locked case, perhaps you could block module autoloading
until the user has logged back in. It's roughly similar to the approach Apple
takes with Thunderbolt, I believe.

~~~
contingencies
My point was not just to disable modules, but to disable all kinds of
unrequired kernel functionality. Recall recent vulnerabilities such as BPF JIT
spraying, etc.

~~~
geofft
Yeah, a hardened kernel is great and I'm glad to see distros building kernels
just for security-sensitive server applications.

However, setting kernel.modprobe to /bin/false is extremely high-impact in
reduction of attack surface compared to how much effort it is (one line in
/etc/sysctl.d/); you can keep running a full-featured distribution kernel,
even one from Fedora or Ubuntu that's simultaneously intended for desktop use.

------
odeke-em
Video demo right here
[https://www.youtube.com/watch?v=lfl1NJn1nvo](https://www.youtube.com/watch?v=lfl1NJn1nvo)

------
pcwalton
This is an excellent writeup, IMO. It's a clear demonstration of how use after
free can be so dangerous.

------
feld
I recall hearing recently that Chrome has access to midi devices ...

~~~
qb45
Fortunately it cannot connect malicious USB dongles. Yet.

