Linux autorun vulnerabilities?

The Windows "AutoRun" feature, which automatically (or semi-automatically after a user prompt) runs programs from removable storage devices, has been a regular source of security problems. It has been present since Windows 95, but Microsoft finally recognized the problem and largely disabled the "feature" in Windows 7—and issued an update on February 8 that disables it for XP and Vista. Various attacks (ab)used AutoRun on USB storage devices to propagate, including Conficker and Stuxnet. Could Linux suffer from a similar flaw? The answer, from a SchmooCon 2011 presentation, is, perhaps unsurprisingly, "yes".

At SchmooCon, Jon Larimer demonstrated a way to circumvent the screensaver lock on an Ubuntu 10.10 system just by inserting a USB storage device. Because the system will automatically mount the USB drive and the Nautilus file browser will try to thumbnail any documents it finds there, he was able to shut down the screensaver and access the system. While his demo disabled both address-space layout randomization (ASLR) and AppArmor, that was only done to make the demo run quickly. On 32-bit systems, ASLR can be brute-forced to find needed library addresses, given some time. AppArmor is more difficult to bypass, but he has some plausible ideas on doing that as well.

Larimer's exploit took advantage of a hole in the evince-thumbnailer, which was fixed back in January (CVE-2010-2640). A crafted DVI file could be constructed and used to execute arbitrary code when processed by evince. In his presentation [PDF], he shows in some detail how to use this vulnerability to execute a program stored on the USB device.

Killing the screensaver is just one of the things that could be done from that shell script, of course. Larimer points to possibilities like putting a .desktop file into ~/.config/autostart, which will then be executed every time the user logs in. The same kind of thing could be done using .bash_profile or similar files. Either of those could make for a Conficker-like attack against Linux systems. In addition, because the user is logged in, any encrypted home directory or partition will be decrypted and available for copying the user's private data.

While Larimer's demonstration is interesting, even though the specifics of his attack may be of little practical use, there is much to be considered in the rest of his presentation. As he points out, automatically mounting USB storage devices and accessing their contents invokes an enormous amount of code, from the USB drivers and filesystem code, to the desktop daemons and applications that display the contents of those devices. Each of those components could have—many have had—security vulnerabilities.

That should give anyone pause about automatically mounting those kinds of devices. One could certainly imagine crafted devices or filesystems that exploit holes in the kernel code, which would be a route that would likely avoid AppArmor (or SELinux) entirely. While Linux may not automatically run code from USB storage devices, it does enough processing of the, quite possibly malicious, data on them that the effect may be largely the same.

Larimer offers some recommendations to avoid this kind of problem, starting with the obvious: turn off auto-mounting of removable storage. He also recommends disabling the automatic thumbnailing of files on removable media. In addition, using grsecurity/PaX makes brute-forcing ASLR harder on 32-bit systems because it uses more bits of entropy to randomize the library locations. Of course, a 64-bit system allows a much wider range of potential library addresses, so that makes breaking ASLR harder still.

One clear theme of his talk is that "automatically" doing things can be quite dangerous. It may be easier and more convenient, but it can also lead to potentially serious holes. Convenience and security are often at odds.