This blog post was originally published in the IT Security Blog on November 1, 2010.

When using MS Windows, even the U.S. military is vulnerable to removable media malware, as explained in the article “U.S. military compromised by removable media malware.” All else being equal, the best way to protect yourself against automatically executing malware infections is to use an OS whose system design philosophy reflects a real concern for security, rather than a security-unconscious OS.

Unfortunately, there are occasional practical realities that require the use of an OS we might otherwise avoid, such as the need to use a particular application, software testing, and employer policy. More often, there are also cases where we think we face such a practical reality even if we do not or where short-term convenience pushes us toward that choice. Other reasons might prompt people to choose an OS that is poorly secured by design as well, such as attachment to the familiar, susceptibility to marketing, or simple ignorance of alternatives.

Regardless of the reasons, when you find yourself using an operating system that is particularly susceptible to vulnerabilities that might not even have meaning on other systems, the impact of those vulnerabilities needs to be mitigated to the extent it is reasonable to do so. The nature of the vulnerability relevant to “U.S. military compromised by removable media malware,” and hopefully made clear in that article, is the danger of the MS Windows AutoRun feature. Simply put, MS Windows executes anything it is told to execute by an autorun.inf file on the removable media.

Several mitigations for the problem were described, including disabling the AutoRun feature, but it is unfortunately the case that this is not always enough. MS Windows updates have been known to reset configuration changes made for security reasons, returning them to default (unsecured) values, for instance. This means that security-related configurations like disabling AutoRun not only need to be set by system administrators but monitored closely for signs of unexpected reversion.

This creates a situation where, even when there is a possible work-around for security issues, some automated technical bandage is needed to minimize vulnerability on MS Windows systems. This problem is a common one, as in the case of MS Windows viruses, which could be dealt with more permanently by patching the vulnerabilities they exploit. Instead, their damage is merely mitigated by a dirty hack: heuristic and signature-based detection. It is at best a kludge, rather than a real solution, to “fix” the problem — but unless and until Microsoft changes its policies regarding vulnerability patching, it is a necessary kludge.

Stay on top of the latest Microsoft Windows tips and tricks with TechRepublic’s Windows Desktop newsletter, delivered every Monday and Thursday. Automatically sign up today!

A similar kludge may be necessary if you want to minimize the danger of MS Windows AutoRun. Luckily, an open source project that targets exactly this malware mitigation problem is available under the appropriate name No Autorun.

No Autorun can be configured to disable AutoRun as a whole or to make exceptions for CD devices. It can also be configured to open a Windows Explorer browsing window to show the contents of USB storage devices without automatically executing anything stored on such devices, making their use more convenient in a controlled manner, in absence of AutoRun.

When my consulting work involved regularly helping small businesses configure, maintain, and (in case of disaster) recover their computers and networks, No Autorun did not exist. It would have been appreciated, however. Since I do not do much of that kind of work now, the opportunities to test malware protection software like No Autorun are few and far between. If you have the opportunity to test it more thoroughly than I have, please share your experiences in the discussion.