Hi, this is Will Dormann of the CERT/CC Vulnerability Analysis team. A few months ago, reports of infected digital picture frames hit the media. I was curious about how the malicious code was being executed, so I began investigating the Microsoft AutoRun and AutoPlay features.

AutoRun, which was introduced with Windows 95, has two primary behaviors:

1. For certain device types, such as CD-ROM drives, Windows will automatically execute the program that is specified in the Autorun.inf file when the device is connected or when media is inserted. The security impact of this feature is that somebody with physical access to a Windows computer can run malicious code by inserting a CD-ROM into the drive. But we already know that physical access to a computer can give an attacker the ability to do just about anything, right?
2. When a drive icon is clicked in Windows Explorer, Windows will execute the program specified in the Autorun.inf file. In this case, user interaction is required for the code to execute. However, the AutoRun behavior can be unexpected, as it is common to believe that clicking the drive icon will display the contents of the drive, rather than executing code.

In the process of investigating AutoRun behavior, I noticed two interesting things:

1. With Windows Vista, the NoDriveTypeAutoRun registry value actually has the opposite behavior than what Windows has documented. In other words, if you think that you have protected yourself by restricting AutoRun with this registry value, you have actually put yourself at additional risk. We have published details about this issue as US-CERT Vulnerability Note VU#889747. The end result here is that a user may inadvertently execute code by clicking on the icon for a device, such as a USB thumb drive.
2. Although the documentation for NoDriveTypeAutoRun indicates that Windows will not use AutoRun features on USB mass storage devices, this does not necessarily mean that users can safely plug any USB device into their system. For example, a system will recognize Sandisk U3 USB devices as both a CD-ROM device and a USB mass-storage device. Considering that an attacker can easily modify the CD-ROM contents of a U3 device, you now have a way for an attacker to execute code of their choice on a Windows system by simply plugging in a small USB device. No other user interaction is required.

The information about malicious use of U3 drives is not particularly new. But how many systems have AutoRun disabled? One aspect that makes the problem confusing is that it is not obvious how to disable AutoRun precisely and effectively. VU#889747 originally listed several steps that appeared to be effective in my testing, but they also had the adverse effect of disabling MCN messages, which can prevent Windows from detecting when a CD-ROM or DVD is changed.

One of our readers has provided us with a workaround that disables AutoRun closest to the source, which is the Autorun.inf file itself. By importing the following registry key, the Autorun.inf file will no longer be used to determine AutoRun and AutoPlay actions:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

This setting appears to disable AutoRun behaviors without causing other negative side-effects. More details about this workaround are available in Nick Brown's blog entry Memory stick worms.

Update (November 21, 2008):

Microsoft Windows may cache AutoRun information from connected devices. The impact of this feature is that even after disabling AutoRun as described above, you may still experience AutoRun behaviors for devices (USB drives, network shares, etc.) that have been connected to the computer in the past. For this reason, we also recommend removing this cache by deleting the MountPoints2 registry key for each user:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2