Nearly 18 months after it was discovered, Microsoft has finally fixed a hole in the AutoRun function of older Windows versions that allowed viruses to spread via external storage devices.
While it's good to know Microsoft is finally listening to the complaints of the Windows community, the company's delay in applying important patches put our systems at risk unnecessarily.
The old saying about the squeaky wheel getting the grease applies to the manner in which Microsoft prioritizes its product fixes. The more noise customers make, the more likely the problems will be rectified. Most recently, the Conficker worm has been spreading across networks, often entering systems via USB flash drives and other removable media. Shamefully, Microsoft could have — and should have — prevented this massive infection from happening in the first place.
In October 2007, Nick Brown documented in his blog how viruses and worms were entering his network via USB memory sticks. The next month, WS associate editor Scott Dunn explained in a Top Story on Nov. 8, 2007, the fact that Microsoft's suggested settings to disable AutoRun weren't effective. He described the so-called @SYS trick, which allows you to truly disable AutoRun, preventing infected devices from launching their attacks.
Fast-forward to one year ago. Will Dormann and US-CERT (the United States Computer Emergency Readiness Team) published information on Mar. 20, 2008, confirming that Microsoft's AutoRun advice didn't block threats. The same @SYS workaround that Scott documented was supported by US-CERT in its alert.
In July 2008, Microsoft released security bulletin MS08-038. The patch in this bulletin made it possible for users to control AutoRun properly, but only on Windows Vista and Server 2008.
XP, Win 2K, Server 2003 users left in the lurch
So what happened to the equivalent patch for Windows 2000, XP, and Server 2003? In May 2008, Microsoft had in fact released a patch for these systems, which is described in Knowledge Base article 953252. However, as described in a Jan. 22, 2009, Computerworld article, US-CERT found that the fix for XP/2000/2003 had to be applied manually. Furthermore, Microsoft was not making the patch available automatically via any Windows Update service.
It wasn't until Feb. 24 of this year that Microsoft distributed this patch via Windows Update to XP, 2000, and 2003. This is described in the company's security advisory 967940.
Many home and business PC users rarely deploy patches that aren't available through Windows Update, Microsoft Update, or WSUS (Windows Software Update Services). Add to this the confusing and conflicting information about the AutoRun patch, and it's no wonder the Conficker worm, which exploits AutoRun functionality, made the inroads that it did.
You may be wondering why it took Microsoft so long to distribute for XP/2000/2003 users the fix that permits AutoRun to be properly disabled. One clue may be found in the file versions listed in KB article 967715. The Windows Server 2003 files are dated Feb. 10, 2009. Typically, Microsoft doesn't release a fix for one platform if it's still developing a fix for another platform. This is done to avoid putting one set of customers at risk while protecting others.
That's usually a valid reason to wait before distributing patches. But when you open up the files described in the earlier KB article 953252, you find that all the files in that hotfix date back to mid-2008.
Why did it take an admonition from CERT to convince Microsoft to add this vital fix to Automatic Updates for those versions of Windows? To make things even more confusing, the way Microsoft released the XP/2000/2003 fix at the end of February caused many people to think it was an out-of-cycle security patch.
If this patch had been pushed to all Windows users sooner, much of Conficker's pain might have been avoided.
Microsoft's Feb. 6 TechNet alert makes the problem clear. Among other things, the Conficker worm uses the AutoPlay feature (which is related to but separate from AutoRun) to infect PCs via USB drives and other portable storage devices. This vulnerability occurs even if the systems have installed the update described in Microsoft security bulletin MS08-067. Therefore, the TechNet article recommends disabling AutoRun, saying:
- "Disable the AutoPlay feature through the Registry or using Group Policies, as discussed in Microsoft Knowledge Base article 953252. Windows 2000, Windows XP, and Windows Server 2003 customers must deploy the update associated with Microsoft Knowledge Base article 953252 to be able to successfully disable the AutoRun feature. Windows Vista and Windows Server 2008 customers must deploy the security update associated with Microsoft security bulletin MS08-038 to be able to successfully disable the AutoRun feature."
(What's the difference between AutoRun and AutoPlay? AutoPlay associates multimedia file types with specific applications, while AutoRun executes autorun.inf files found on various drives. For more on the distinctions between AutoRun and AutoPlay, see Microsoft's help article on the subject.)
For home users, I'm not yet ready to pull the fire alarm and tell everyone to disable AutoRun. But I do urge you to be very leery of plugging USB flash drives into your system if you're unsure whether they've been used on other computers. Large organizations, however, should consider disabling AutoRun on their networked PCs, considering how hard it's been to stomp out the Conficker worm and others.
How to apply the patches and control AutoRun
If you followed the instructions in Scott's 2007 article to block AutoRun by adding a Registry key, you should remove the key before applying the Microsoft AutoRun patch to prevent any possible interaction. Take the following steps for complete protection:
- Step 1. Remove the @SYS line from the Registry, if you added it. In Windows XP, click Start, Run. (In Vista, click Start.) Type regedit and press Enter. In the left pane, navigate to and select the following key:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ IniFileMapping \ Autorun.inf
Press the Del key to remove the key. Close the Registry Editor. - Step 3. For security reasons, it's strongly recommended you disable AutoRun for all devices. In non-Home versions of XP and Vista, use the Group Policy Editor. In XP, click Start, Run. (In Vista, click Start.) Type gpedit.msc and press Enter. In the left pane, under Computer Configuration, expand Administrative Templates.
In XP Professional, select System in the right pane under Administrative Templates, right-click Turn off Autoplay in the right pane, and choose Properties. Click Enabled, select All drives in the "Turn off Autoplay" box, click OK, and close the Group Policy Editor.
In Vista Business and higher, expand Windows Components and select AutoPlay Policies. In the right pane, double-click Turn off Autoplay, click Enabled, choose All drives in the drop-down menu next to "Turn off Autoplay on," click OK, and close the Group Policy Editor.
To disable AutoRun in the Home versions of XP and Vista — which don't have the Group Policy Editor — use the Registry Editor. In XP, click Start, Run. (In Vista, click Start.) Type regedit and press Enter. Navigate to and select the following key:
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ Explorer
In the right pane, double-click NoDriveTypeAutoRun, enter 0xFF in the "Value data" field, make sure Hexadecimal is selected under Base, click OK, and exit the Registry Editor. - Step 4. If you ever need to re-enable AutoRun for a certain system, open the Group Policy Editor (on non-Home versions of Windows) or the Registry Editor (Home versions). Then follow the instructions in KB article 967715 (for XP, 2000, and Server 2003) or 953252 (for Vista and Windows Server 2008) to return AutoRun to its default state or customize its settings. AutoRun can be configured, for instance, to work differently for CD-ROMs than for other media.
Once you've disabled AutoRun, you'll have to use Windows Explorer to access data files on the USB memory devices and optical media you insert in your system. If you load a disc that contains audio or video, you may want to open your favorite media player to run the content. However, this is a small price to pay for the security edge you gain by disabling AutoRun.
by: Susan Bradley (with thanks)
No comments:
Post a Comment