I documented implementing the Brown/Atac approach back in January in The best way to disable Autorun for protection from infected USB flash drives. It requires updating the registry to instruct Windows to ignore all autorun.inf files. Specifically, you need to run the three-line registry update below.
REGEDIT4 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionIniFileMappingAutorun.inf] @="@SYS:DoesNotExist"
Save these three lines of text in a file. The file name can be anything, but the type needs to be ".reg". Once this is done, simply double-clicking on the file updates the registry. In the unlikely event this causes a problem, it's easily backed out (see below). Still, it is always a good idea to make a Restore Point before updating the registry.
Vista users can read about the behavior differences introduced by the Brown/Atac approach in Disabling Autorun and Autoplay on Windows Vista SP1 with Nick Brown's method.
I am not a lone wolf in advocating for the Brown/Atac approach to disabling autorun.
Back in November of 2007, Scott Dunn wrote One quick trick prevents AutoRun attacks in the Windows Secrets newsletter shortly after Nick Brown first documented the scheme.
In January 2009, US-CERT issued a Technical Cyber Security Alert called Microsoft Windows Does Not Disable AutoRun Properly that warned "The Autorun and NoDriveTypeAutorun registry values are both ineffective for fully disabling AutoRun capabilities on Microsoft Windows systems" and then suggested using the Brown/Atac registry zap.
This was old news for US-CERT. Back in March 2008 they issued Vulnerability Note VU#889747 Microsoft Windows fails to properly handle the NoDriveTypeAutoRun registry value which also suggested using the Brown/Atac scheme.
Then, ask-leo.comLeo Notenboom broached the subject in February 2009 with Is autorun really that evil, and if so, how do I turn autorun off? He didn't even mention a Microsoft solution to disabling autorun, rather he focused solely on the Brown/Atac approach. Leo also does a good job pointing out the downside to totally disabling autorun. You can have convenience or security. Pick one.
My previous blogs, the articles above, and perhaps 99% of what's available online about autorun/autoplay, pre-dates Windows 7.
My testing showed that Windows 7 blocks running software on a USB flash drive. Specifically, it ignores instructions in the autorun.inf file to add an entry to the AutoPlay window (shown below) and the context menu. Double-clicking on the drive letter in Computer lists files on the drive, regardless of instructions in the autorun.inf file.
The new operating system does, however, allow the autorun.inf file on a USB flash drive to modify the displayed volser and icon for the drive. You see this in the example below, where the icon comes from a copy of Paint on the USB flash drive and the displayed volser comes from the autorun.inf file.
This, however, does not mean that Windows 7 is immune to infection from malware on external media. It's safer, but not safe.
For one thing, Windows 7 still supports autorun/autoplay for CDs and DVDs. And then there are USB devices that pretend to be CDs. Pretend? What pretends to be a CD? U3 flash drives for one. My LG Chocolate 3 cellphone for another.
The Chocolate 3 phone, released in mid 2008, is big on playing music. To make it easy for users to sync music between the phone and a computer, LG makes the phone appear to Windows as a CD drive. Thus, when the phone is plugged into a USB port, the LG software runs automatically, there is no Windows AutoPlay window offering any confusing choices.
To be fully protected, the Brown/Atac registry modification is still needed on Windows 7. It disables autorun everywhere, offering protection from CDs, DVDs and devices that pretend to be CDs. My testing turned up no ill effects.
The Brown/Atac registry zap can be un-done, if need be, even under Windows 7. Backing out the change was first tested over two years ago, but I verified that it still works under Windows 7. As with earlier versions of Windows, you run regedit.exe, delete a key in the registry and re-boot. Instructions are at the end of Browns original blog posting.