Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

Improvements to AutoPlay

Improvements to AutoPlay

  • Comments 59

As mentioned before on this blog (regarding our UAC changes) and on the IE blog (regarding the SmartScreen® filter for malware), we have an increased focus to enable customers to be in control and feel confident about the software that they choose to run on their computers. Folks on this blog have also commented about the concerns they have specifically in the AutoPlay area. This blog entry addresses some of the changes that we have made to increase customer confidence when using their media and devices with Windows.  It is authored by Arik Cohen, a program manager on the Core User Experience team. –Steven  [Note: There was a technical problem so this post was reposted in its entirety.]

Certain malware, including the Conficker worm, have started making use of the capabilities of AutoRun to provide a seemingly benign task to people – which masquerades as a Trojan Horse to get malware onto the computer. The malware then infects future devices plugged into that computer with the same Trojan Horse. For further information about Conficker please visit http://www.microsoft.com/protect/computer/viruses/worms/conficker.mspx

In the following example for a USB flash drive that has photos, malware registers as the benign task of “Open folders to view files.” If you select the first “Open folders to view files” (circled in red), you would be running malware. However, if you select the second task (circled in green), you would be safe running the Windows task.

Infected USB AutoPlay
Infected USB AutoPlay

People are confused why they have two tasks that appear to do the same thing – and even a knowledgeable person who is careful not to run software from an untrusted source can easily make the mistake of selecting the first task. As a result, people lose confidence and don’t feel in control.

A growing attack

While presenting an AutoRun task in AutoPlay has been available since Windows XP, we have seen a marked increase in the amount of malware that is using AutoRun as a potential method of propagation. According to the Security Intelligence Report, an enterprise study by Forefront Client Security found that the category of malware that can propagate via AutoRun accounted for 17.7% of infections in the second half of 2008 – the largest single category of malware infections.

The chart below shows the increasing amount of detection reports by Microsoft anti-virus software of the class of infections that spread via AutoRun. (Note: The actual method of infection cannot be determined.)

Infection Detections of Malware that Spread via AutoRun

Infection Detections of Malware that Spread via AutoRun

Currently, disabling AutoPlay completely is the only solution for consumers and enterprises to gain confidence with the use of USB flash devices on their computer. Guidance on disabling AutoPlay is available here.

Increasing customer confidence

Windows 7 introduces key changes to AutoPlay that keep you from being exposed inadvertently to malware like Conficker when doing your common scenarios with devices (e.g., get to the files on your USB flash drive, download pictures from an SD card, etc.).

In particular, Windows will no longer display the AutoRun task in the AutoPlay dialog for devices that are not removable optical media (CD/DVD.) because there is no way to identify the origin of these entries. Was it put there by the IHV, a person, or a piece of malware? Removing this AutoRun task will block the current propagation method abused by malware and help customers stay protected. People will still be able to access all of the other AutoPlay tasks that are installed on their computer.

With these changes, if you insert a USB flash drive that has photos and has been infected by malware, you can be confident that the tasks displayed are all from software already on your computer:

Infected USB AutoPlay after AutoPlay changes

Infected USB AutoPlay after AutoPlay changes

On the other hand, if you insert a CD that offers software to install, Windows will still display the AutoRun task provided by the ISV during their media creation process. For example:

AutoPlay for a CD that offers an AutoRun Task

AutoPlay for a CD that offers an AutoRun Task

You will first see this updated AutoRun experience in the Windows 7 RC build, and we will be bringing this change to Vista and XP in the future.

Ecosystem Impact

We are working with our ecosystem partners to help mitigate situations where this AutoRun change will have an impact on them.

CDs and DVDs (including CD emulation), where the IHV specified AutoRun task authored during manufacturing, will continue to provide the AutoRun choice allowing customers to run the specified software. IHVs of generic mass storage devices should expect that people will browse the contents of the device to launch any software. The new behavior will allow customers to continue to use AutoPlay (including all Windows and ISV installed tasks) to access their media and devices while not being presented with tasks from malware. Additionally, device classes, such as portable media players and cell phones, now support Device Stage™ on Windows 7. Device Stage offers the IHV a multifunction alternative to AutoPlay where they can present links to software and common tasks, and provides additional features as you use the device.

As you try out the Windows 7 RC, we hope these changes will make you feel more confident and in control when using your media and devices.

-Arik Cohen

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • Manicmarc, a Microsoft app store would surely require signed code, which would become a $200-$500/year entry fee that would exclude a lot of software.

  • Why not turn General Options to green buttons?

    Like "Open folder to view files" option, why not turn it to a green button or a green-circle button?

    A autorun malware cannot simulate this behavior, I think. Unless malware was activated first, it wouldn't interfere.

  • How about this idea; get rid of the feature. It is of no measurable benefit to anyone and is a massive security vulnerability that you could fly a 747 through.

    If you want to install something - you have to manually open the cd and double click on the setup.exe file - something that most people are used to anyway so there is no loss by removing the feature in the first place.

  • This will break most GPRS modems! (For non-tech-savvy users.)

    Those usually come in the form of a USB drive with the modem driver installing through Autorun once the drive is plugged in - a very convenient, zero-configuration system that works well.

    With Autorun turned off for USB drives, the user will have to navigate to the drive and often make his choice between multiple executables with nondescriptive filenames. At least some GPRS modems (I have one like it) do NOT provide any instructions for this case in their manual. The "no knowledge required", plug-and-play experience is definitely gone this way.

    I strongly believe that this should be reevaluated. Ideally, a prompt would be shown asking whether the drive should be autorun, along with an appropriate warning message (something which, by the way, should be introduced with optical drives as well).

  • limulus -> Break is perhaps an overstatement since you can manually run the app and some people already have the feature disabled anyways.

    It will, however, degrade the end user experience.

  • I think disabling autorun alltogether is a realy bad idea.

    There are good reasons to use autorun. I'm using a USB-Harddisk with TrueCrypt. If you plug in the drive you can automaticly mount the truecrypt volume using the entry displayed in the autorun dialog.

    Without autorun you have to start truecrypt and set all the options, which are normally set by using command line options in autorun.ini, manually.

    I think enabling autorun for signed executables is a good compromise.

  • Short-sighted move.  I've found autorun very useful for utilities I place on a USB drive.  For example, insert the USB drive, launch the portable TrueCrypt to auto-mount my secure volume.

    Vista had a good practice of asking if you wanted to autorun. Disabling it totally will be annoying.  If you're going to disable it, at least give those of us who know what we're doing the option to go into Control Panels and turn it back on.

    It worked with UAC: giving me the option to turn it off completely kept me from hurling my Vista PC out the window.  (Three separate UAC prompts to create a new folder in my start menu and move something into it kinda sent me over the edge.)  I turned off UAC and have no problems with malware. Autorun (especially with the "ask first") is not going to cause me problems either.

  • Thank you for the feedback.  I wanted to chime in directly on limulus's comment about GPRS modems.

    In our testing, most of the GPRS modems are not affected by the change because they expose their driver partition as a emulated CD drive.  This partition can continue to display an AutoRun task to you.  For example, the TRU-Install driver installation used by many of these devices like the Sprint Compass 597 or O2 Compass 885 continues to run without any changes.  

    Because a particular device must declare itself as a emulated CD drive in the firmware of the device, we can trust that the IHV has done that for the purpose of exposing the device content like their physical installation CDs and malware cannot cause a generic USB flash drive to mimic this experience.

    - Arik Cohen

  • I was wondering what the requirements are for "Publisher not specified" vs. "Published by ..."

    Microsoft tends to be somewhat inconsistent here, and it could be a healthy opportunity to revise the specs.

    At different times (security warnings when running a local/online/blocked file, properties, etc.), the publisher name shown to the user is either taken from the digital signature, or from the resource (RC). This duality is not good, especially when the two strings are different.

    Additionally, different requirements exist for what constitutes a "trusted" digital signature: for some parts of the Microsoft universe, only a Class 3 code signing certificate by providers such as VeriSign is good enough (e.g. for Winqual/logo purposes). For others, any signature will do (Thawte, Comodo, etc.)

    As some have posted here, it would be good to at least demand that any executable code that is invoked by AutoRun be signed. I fully agree with that. As the dialogs indicate, the choice has already been made to expose a publisher name to the user, so this should IMHO come from the Authenticode information, and nowhere else (not from the simple file properties).

    While agreeing to the signing requirements, I'd also have to add that this would not solve the issue of malware. Drivers also have to be signed, yet unsigned code can exploit a driver to invoke something else. While this is generally malicious, an AutoRun application usually does this by design, because AutoRun launchers such as MenuBox are there exactly to open a window and propose some options which include launching an installer, running an application from CD or USB, etc. USB itself is increasingly chosen as an application distribution medium (while standards are on the rise to trust the USB medium).

    HTML Applications (HTA files) are another example, similar to an AutoRun launcher application. By design, Microsoft allows HTAs to be unsigned and to run executables. Which is great for AutoRun. Should we break this, only because of some new signature requirements? Even if you signed the first layer, the second layer (invoked by HTA or apps like MenuBox) would still not be subject to the same requirement.

    My opinion is that at the very least, "Published by ..." should have information coming from Authenticode. If the application is unsigned, it should be marked as such. This is because you are providing this information to the user with respect to this specific application, and the information should be as accurate and trackable as possible.

    For the rest, the issue is more complex than it may seem at first sight, and autoRun itself is not the (only) problem. IMHO, code signing should be a requirement for all executables, at least in an optional way, if you want to raise the bar for what may or may not run on a PC. So any user, home or corporate, could have a list of trusted application publishers, if desired, and the surface for malicious code management would be narrowed a lot. Code exploits and social engineering will always exist, but if all code were signed, from Windows system executables, to applications, management would be easier. Doing this in a "leaky" way will always favor the unpatched scenario, be that a USB key that looks like a CD drive to the system, or a second layer that is not subject to the restrictions of the first layer, like unsigned code run by signed code.

    At the end of this, I just noticed that Windows 7 has a feature called "AppLocker", which I haven't seen yet. It may do what I was talking about, with respect to only allowing signed code with certain requirements to run. I hope that AutoRun and AppLocker will work hand in hand, giving the user the option to add a publisher that is "introduced" in an AutoRun context to the AppLocker list, without jumping through too many dialogs.

    Just my two cents!

    Mike

  • Be aware that optical discs (CDs and DVDs) are routinely used as an attack vector by malware.  To cite just a few examples, there's the W32.Mabezat, W32.HLLW.Infex, and W32.Serflog families, which add their own executable and autorun.inf to the %UserProfile%\Local Settings\Application Data\Microsoft\CD Burning  directory, so any disc the user burns will be infected.  

    This is historically a pretty widespread tactic, so keep it in mind.

  • @ Arik Cohen:

    That is very interesting. I wasn't aware of this functionality in those drives. To me it always looked like they are just standard USB drives.

    I have to admit that the idea of emulating a CD drive for this purpose is amazing.

  •  I understand the threat and concerns of virus spreading through removable drive by Microsoft and limit this auto play feature is a good thing.  However, if we totally disable the autorun feature for all removable drive will have an affect with some removable drive products.

     I'm using a secure USB drive where instead of using CDs emulation to auto launch the application to unlock the secure partition by taking advantage of auto play feature for CDs, this drive would just show as a normal read-only removable drive and launching the application to unlock the private partition with the autorun feature.  Thus, when this feature is turned-off for all the removable drive the user experience will have an impact.

     In my opinion, to be fare with all the CDs emulator drive where autorun doesn't get turned off, Microsoft products should still let's the autorun and autoplay feature available for all READ-ONLY removable drive, media.  Thus it won't affect lots of removable media already out in the market.  

    Phong

  • That's a good thing to disable this thing at all, that was a wide security whole. At present I fear each time someone want to plug a USB drive onto my computer, and most of the time there is some kind of malware. Autorun or Autoplay should never had existed.

    To those who complain about it, it's not that difficult for the user to explore his drive and launch what he wants, only two clicks, are you so lazy ?

    There still remains the kind of malware who hide the folders and create some executables files named accordingly to the hidden folders. For that, it would be nice to have a way to differentiate an executable file from the others !

  • Finally installed the RC. Just wondering is there any settings for Aero Peak? It would be great to have an application exclusion list or something. We have the Sticky Note which makes a useful gadget but disappears on Aero Peak. :( Actually what is the reason for Aero Peak if it hides everything? So you can have a peak on your desktop background? Yeah ok it keeps the desktop gadgets. But those are not really useful. it should keep the Calculator, Sticky Notes, Contacts, Character Map basically a there should be a customizable list of software.

    Love the ability for displaying UTC time though.

    Also there should be a way to control network traffic (controlling upload/download speed and schedule) natively in the OS. I use Netlimiter but it is crashing under W7.

    Anyway W7 is nice unforunatelly lots of cool feature have not made it into  the RC. (like multiple desktops) Wonder why, concurrent OS-s have that for ages now. All to gather it is how Vista should have looked like 3 years ago. Nothing revolutionary compared to Vista SP1 just more cleaned up.

    Again very nice OS but somehow it is missing the edge, the one that cuts.

  • This interferes with Ceedo. WHYYYYYYYYYYYYYYYYYYYY? I LOVE CEEDO!

Page 2 of 4 (59 items) 1234