Microsoft is seeking to avoid a repeat of February's blue-screen problems with this month's bumper crop of Patch Tuesday patches. After installing the February updates, some users of Windows XP found their systems wouldn't boot. After investigation, this turned out to be due to an interaction between the Alureon rootkit and the patch for KB977165 which updates the Windows kernel. Microsoft has subsequently released tools that attempt to detect the rootkit and prevent installation of the patch if a machine appears compromised.
This month's patches also contain kernel updates, and so have the same incompatibility with the rootkit. As the bulletin for MS10-021 states, "This security update includes package detection logic that prevents the installation of the security update if certain abnormal conditions exist on 32-bit systems. These abnormal conditions on a system could be the result of an infection with a computer virus that modifies some operating system files, which renders the infected computer incompatible with the kernel update."
No exploits of this flaw appear to exist in the wild so far, but Microsoft warns that exploit code is likely to be developed. This makes patching sooner rather than later highly advised.
Though the rootkit-detection avoids blue-screening affected machines, it also means that the flaws remain unpatched. Given the severity of the problems being fixed, this is far from ideal. It is, however, understandable; the problem in February had consequences beyond a small minority of machines that could not boot. The issue was widely reported, and there's a risk that people will refrain from installing essential patches out of fear that their machines too will be left unusable. People being fearful of security updates is a disastrous outcome for both Microsoft and the world at large.
The position Microsoft is in is an awkward one. Extant security exploits are causing the company to leave flaws unpatched, and hence vulnerable to further exploitation. These exploited machines are a substantial nuisance to the Internet as a whole—exploits are used to recruit machines into botnets which then send spam, launch denial-of-service attacks, and further propagate malware—so clearly the most desirable outcome is that these machines be cleaned up and then patched.
For users of the Internet, if not the owners of these compromised machines, being patched, blue-screened, and hence inoperable is the better result. That will, at the very least, indicate to the owners that something is wrong and their machines need to be fixed. But the risks of consequential refusal to install patches, not to mention the PR problems, makes the approach untenable. As distasteful as leaving infected machines unpatched is, the first step has to be removal of the rootkit.
But Redmond can't simply clean a computer unprompted. Rootkits are designed to be hard to detect and hard to remove, so the mere act of cleaning them from a machine carries some risk. Further, the company simply isn't entitled to make that kind of change to systems without permission. Though the company distributes its Malicious Software Removal Tool, which can remove a range of common exploits (including the Alureon rootkit), this tool is not installed automatically by Windows Update in its default configuration. To install it, Windows Update must be configured to install "Recommended" updates (it defaults to only installing "Important" ones), and the first time it is run, its license terms must be agreed to.
As such, even users who allow Windows Update to update their systems automatically won't, without further intervention, have such malware removed, and so will be blocked from future kernel patches.
This problem is only likely to grow worse with time. Until cleaned, the infected machines will be vulnerable to an increasing number of kernel flaws, leaving them exposed to new threats. With little chance that owners of affected computers will clean them up of their own volition, Microsoft might yet be forced to take some more aggressive action to get them clean and up-to-date.
![Morgue[FLB]](/thumb.php?src=%7Be_AVATAR%7Dupload%2Fap_59_morgueflb.png&aw=100&ah=100)