Deeper insight into the Security Advisory 967940 update

Hi!  I'm Adam Shostack, a program manager working in TWC Security, and I'd like to talk a bit about today's AutoRun update.   Normally, I post over on the SDL blog, but of late I've been doing a lot of work in classifying and quantifying how Windows computers get compromised.  One thing that popped from that analysis was the proportion of infected machines with malware that uses Autorun to propagate.

You might note that that's a convoluted sentence, and I apologize.  Why can't I just say "infected because of AutoRun?"  Well, because we don't actually know that.  Due to the nature of the problem, it's probably not possible to acquire great data on the number of attacks that succeed by misusing Autorun.   What we know, and talked about in volume 9 of our Security Intelligence Report last fall, is that a lot of malware uses Autorun as one of several propagation mechanisms.  Because of the very real positive uses of Autorun, we didn't want to simply shut it off without a conversation. On the other hand, we believed action should be taken to shut down the misuse.

In April 2009 we delivered a very public message to the Windows ecosystem that we were changing the behavior of Autorun in ways that improved security. We blogged on the progress of that transition, posting "AutoRun changes in Windows 7" in April 2009.  In November 2009, we posted "AutoPlay Windows 7 behavior backported" and we put out an update to do the same for older operating systems. We made that update available from the Download Center. That allowed anyone who wanted the update to seek it out and download it for themselves. Our partners expressed their concerns about that change, but by and large understood the reasons for it.  Over the last few years, companies that needed the functionality incorporated U3 functionality into their devices.  Others documented the change.  Overall, the transition hasn't been simple, but it has worked.

Today we are taking another important step to protect our customers. We're putting the existing update into the Windows Update channel.  This change has three important effects:

  • We deliver the existing update to many more machines;
  • We make it easier to deploy via WSUS;
  • We help those organizations that, as a matter of their policy, only widely deploy updates that are in WU.

We're marking this as an "Important, non-security update."  It may seem a little odd to call this a "non-security update," especially since we're delivering it alongside our February bulletins.   But at Microsoft we reserve the term "Security Update" to mean "a broadly released fix for a product-specific security-related vulnerability."  And it would be odd to refer to Autorun as a vulnerability.  That term is generally used, and we use it, to mean accidental functionality that allows someone to violate the security of the system.  But Autorun isn't an accident -- it's by design, and as I mentioned we care about the very real positive uses of the feature. In other words, in a very real sense, it's not a bug, it's a feature, and we documented it as such. 

It's also not a security update because security updates are intended to fix a problem and all known variants.   That's more problematic when the "problem" is a feature that's being used as intended, and so this update does not turn off the feature entirely.  For example, it does not impact "shiny media" such as CDs or DVDs that contain Autorun files. We are aware that someone could write malware to take advantage of that, but we haven't seen it in the wild. (We also think malware on shiny media would be less likely to have widespread impact, because people burn CDs less often than they insert USB drives.) 

Based on what we've learned over the last 22 months and shared in the SIR, now is the right time to bring this update to a wide audience. (The MMPC blog today has further insight into that aspect of this update.) At the same time, we're aware that some customers prefer the existing Autorun functionality and will want to reverse the effects.  So we have a Fix It available that accomplishes that.

Changing behavior for a running system is never a trivial thing, and we take it incredibly seriously.  It would be a bad outcome for people to think they have to make a tradeoff between security and anything else.  Updates to protect against vulnerabilities are an important part of keeping a system secure.  We had to be very confident that this change was the right balance for most people.

Adam