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 4 and 5 and type the answer here:
  • Post
  • Nice job, as always.

    Keep the information.

    W7 best OS from Microsoft Ever.

  • I like the fact that security is taking precedence here, but this can be bad in certain situations.  For example, I have a flashdrive running Portable Apps.  Because AutoRun is disabled, it will be much more difficult to launch the program.  The option to reenable AutoRun for removeable media should be able to be changed through the control panel, so those who actually know what they are doing can have ease of access as well as security.

    Thanks, and I can't wait for the release of this awesome OS!

  • This is a short-sighted half solution.

    Code-signing the autorun.exe applications would be more significant for future looking improvements.

    Using mutlitple hashes to check against a database  in a method similar to IE's phishing filter can cover older software.

    If the system is off the internet or an item is not in the database on way or the other, you can use a warning dialog to indicate that there is no way to verify the authenticity of the application much in the way that unsigned activeX controls get treated in an intranet setting.

    For corporate environments, allow AD policies to supliment these databases.

    And then apply this across autoplay unilaterally.

    When possible you verify what IS trustworthy, protect users when recognized threats are found and warn them against potential threats when nothing can be verified.  This way, the system can grow, be reactive and actually engender a sense of trust that users can actually rely upon.

    Just randomly turning off autoplay leaves gaping holes in the system that WILL eventually be exploited in ways you have not yet expected.  Surely, we have seen enough of those types of solutions?

  • This is a good move, but unfortunately this won't cover those malware which deliberately use an icon that looks like a folder for their executable. Those cannot be differentiated from folders at a first glance, unless extension hiding is disabled. That also make the user "lost confidence and don't feel in control". Why not provide an option to disable silent code execution from removable drives (prompt before any executable can be run from a removable drive), with an user-managed whitelist to allow certain executables (verified by hash-checks) to bypass the prompting?

    Or overlay all executables with a marker that identifies them as executable files.

  • Nice nice nice JOB  !!!

    Windows 7 is coming.. resistence ?? FUTILE :D

    Go Team !!

    5 May coming soon

  • 5 may eh?

    Isn't 7100 build was compiled few days ago? And the article dated april 27. So, I barely doubt any features after build7100 date will be included in RC.

    Or, may be, it is just delayed articles, idk...

  • What is annoying the hell out of me is that whenever I dock my laptop I get an Autoplay window, since I have a USB hard drive for backups connected to the dock.

    It makes me mad that I cannot disable it, only if I get rid of it for all USB removable devices.

    I would like the option to turn off Autoplay for specific devices, not just categories.

    @Kein

    You shouldn't expect the developers to run here and quickly type in their newest changes whenever they decide on them. Most of the articles are in-depth views of features that are already implemented.

  • soumyasch: Ya man I agree with you. I wish Microsoft had done that. It would be really great even for a novice.

    And this is another good move by Microsoft :)

  • Excellent. AutoRun has always had security issues, AutoPlay was a much better effort. Removing AutoRun from AutoPlay is a solid improvement as AutoPlay handlers are fully customizable. But when malware gets onto the system in the first place and registers as an AutoPlay handler, we will get a UAC prompt right? If not, why not introduce UAC prompts when AutoPlay handlers are registered?

  • Two comments here. First, where is the secure workaround to allow autoplay? We're providing a product to some clients who specifically want absolutely automatic and transparent install just by plugging in a USB stick. Admittedly, they're not running Win7, and the chance of them upgrading to it any time soon are nonexistent, but it doesn't change that in a couple of cases autoplay may pretty much be a necessity. So some option to sign the executable or similar, to allow autorun to work, please?

    Second, a more personal annoyance. This means that most of the time, we will s the autoplay dialog pop up *with only one option*. So why show it at all? Why not just open Explorer directly, if that is the only option displayed anyway?

    The alternative is clumsy, and looks unprofessional. It gives the impression that you never even thought about how to make this convenient for the user (which may be true, but shouldn't be)

  • I've read every entry on this blog and I've been astonished how well thought out and engineered it's all been.

    This concept however seems like a knee-jerk reaction to recent security hole. Some of the other suggestions in these comments sound like a much more sensible way of dealing with the problem rather than "someone hacked it, so just disable all of it!"

    Thanks for your great work so far and I hope you'll consider changing this decision.

  • I would have to agree with a few of the other posts on here.  This feels like a dodgy workaround for a deeper issue.  Simply not showing the autorun tasks in removable media doesn't really stop any infection, it just prolongs the process.  I like the ideas that Xepol had posted for more secure autorun actions.

    Maybe you just need to provide us with a bit more detail on this method.  However, right now, I don't get any warm fuzzy feelings about what you just wrote.

    On the whole, I think Microsoft is doing a wonderful job, but this area is deffinately lacking.

  • A very nice start, but while this will slow the spread of malware via flash drives, there's still a huge hole open if you're keeping the optical drive autorun feature.  People are still generally dumb and a number of them will still put in a CD without thinking about it.  There are also U3 USB keys which appear to Windows as an optical drive.

    I think disabling all executable autorun whatsoever is the better option.  Yes it means the user might need to (oh no!) double-click setup.exe on their own, but it's far better for security.  Neither OS X nor Linux has autorun for a reason.

  • Autorun from portable devices has never been useful, don't listen to the short-minded asses here.

    It's only matter of several minutes to write, say, lightweight shell service which will reintroduce this functionality better way for caring program vendors.

  • "To enable customers to be in control and feel confident about the software that they choose to run on their computers"

    This may be slightly off topic, but for while now I have been thinking, what Windows really needs is a repository based install system like Linux.

    Microsoft are working on an "App Store" for Windows Mobile, why not Windows 7 (ok too late, maybe Windows 8)

    We need to condition users so when a web page says you need to install this piece of software they click start > app store and search for it.

    I believe this would help in the fight against drive-by downloads.

    What do guys think?

Page 1 of 4 (59 items) 1234