Freigeben über


Improvements to AutoPlay

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 https://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. DeviceStage 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

Comments

  • Anonymous
    April 27, 2009
    Nice job, as always. Keep the information. W7 best OS from Microsoft Ever.

  • Anonymous
    April 27, 2009
    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!

  • Anonymous
    April 27, 2009
    The comment has been removed

  • Anonymous
    April 27, 2009
    The comment has been removed

  • Anonymous
    April 27, 2009
    Nice nice nice JOB  !!! Windows 7 is coming.. resistence ?? FUTILE :D Go Team !! 5 May coming soon

  • Anonymous
    April 27, 2009
    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...

  • Anonymous
    April 27, 2009
    The comment has been removed

  • Anonymous
    April 27, 2009
    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 :)

  • Anonymous
    April 27, 2009
    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?

  • Anonymous
    April 27, 2009
    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)

  • Anonymous
    April 27, 2009
    The comment has been removed

  • Anonymous
    April 28, 2009
    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.

  • Anonymous
    April 28, 2009
    The comment has been removed

  • Anonymous
    April 28, 2009
    The comment has been removed

  • Anonymous
    April 28, 2009
    The comment has been removed

  • Anonymous
    April 28, 2009
    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.

  • Anonymous
    April 28, 2009
    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.

  • Anonymous
    April 28, 2009
    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.

  • Anonymous
    April 29, 2009
    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).

  • Anonymous
    April 29, 2009
    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.

  • Anonymous
    April 29, 2009
    The comment has been removed

  • Anonymous
    April 29, 2009
    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.

  • Anonymous
    April 29, 2009
    The comment has been removed

  • Anonymous
    April 29, 2009
    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

  • Anonymous
    April 29, 2009
    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 SettingsApplication DataMicrosoftCD Burning  directory, so any disc the user burns will be infected.   This is historically a pretty widespread tactic, so keep it in mind.

  • Anonymous
    April 30, 2009
    @ 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.

  • Anonymous
    May 01, 2009
    The comment has been removed

  • Anonymous
    May 01, 2009
    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 !

  • Anonymous
    May 01, 2009
    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.

  • Anonymous
    May 03, 2009
    This interferes with Ceedo. WHYYYYYYYYYYYYYYYYYYYY? I LOVE CEEDO!

  • Anonymous
    May 05, 2009
    I believe this solution disables functionality used by millions of users (the ability to easily start legitimate software installed on portable devices like the PortableApps.com Platform) while still leaving a vulnerability that has been used in the past (malware autorunning from CDs/DVDs like Sony's malicious software fiasco). A better solution would be to check for signed code.  This could be easily accomplished using the existing infrastructure (including revoking remotely) and presented to the user simply with a minimum of coding changes. I've put together a complete proposal with the details and screenshots here: http://johnhaller.com/jh/useful_stuff/windows_7_autoplay/

  • Anonymous
    May 07, 2009
    The comment has been removed

  • Anonymous
    May 13, 2009
    The comment has been removed

  • Anonymous
    May 21, 2009
    I noticed that Internet Explorer 8 automatically checks the hashes of any file downloads, and can block potentially suspicious files. Would it be a better idea to have a similar implementation for the Auto-Play feature?

  • Anonymous
    May 29, 2009
    The comment has been removed

  • Anonymous
    May 31, 2009
    The comment has been removed

  • Anonymous
    June 12, 2009
    The problem has been that the AutoPlay framework "stood still" while a wave of removable media washed over the industry; today, there's just as much a chance that users will insert USB key drives or card-readers than a CD-ROM or DVD. AutoPlay should reflect that fact, as well as anticipate potential abuses.

  • Anonymous
    June 12, 2009
    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 !

  • Anonymous
    June 24, 2009
    I think that a serious problemis the fact that the autoplay framework feature basically froze which a torrent of removable media flooded the market. It is in need of a complete overhaul, I hope to see this in the newly released version of windows.

  • Anonymous
    June 30, 2009
    The comment has been removed

  • Anonymous
    November 15, 2009
    The comment has been removed

  • Anonymous
    November 28, 2009
    Great stuff.That sounds pretty cool. Really helpful thanks for the Article, Great job, hope we can expect more advanced....

  • Anonymous
    February 11, 2010
    So THIS is why my grandmother can no longer plug in her digital camera with her USB cord and have her once smart computer upload her pictures for her.  You have just made her life about 600% harder.  Manually navigating to her pictures is a bit of a difficulty for her at her advanced age, especially when her computer used to do the hard work for her. She is at NO RISK of getting viruses or malware from her own camera.  So how can I fix this horrible "all or nothing" solution you've implemented?  She just wants her camera to automatically retrieve her pictures like it has done for years!

  • Anonymous
    February 15, 2010
    The comment has been removed

  • Anonymous
    March 08, 2010
    I don't like that this feature has been completely removed. There should be an option to enable it for specific devices and specific software that has been approved by the system administration. P.S. Is it on purpose that the posting comments function is not working in Firefox because the code is not displayed.

  • Anonymous
    March 10, 2010
    The comment has been removed

  • Anonymous
    March 15, 2010
    I like this system.And I am using this system.It word powerful.

  • Anonymous
    April 18, 2010
    The comment has been removed

  • Anonymous
    May 04, 2010
    I like this system.And I am using this system.It word powerful.

  • Anonymous
    May 11, 2010
    The comment has been removed

  • Anonymous
    August 18, 2010
    The comment has been removed

  • Anonymous
    August 31, 2010
    Does anyone know whether this update gets downloaded automatically and as a mandatory update or optional update? I have a few machines that behave differently on this KB. Any info would be much appreciated.

  • Anonymous
    December 10, 2010
    What if we want to have a portable program (such as 2-way sync) to auto run? can we still do that?

  • Anonymous
    January 05, 2011
    good..but autoplay itself is not popping out on my windows 7 64 bit home premium..what should i do??

  • Anonymous
    February 08, 2011
    i hope it's not an attack on my magic jack ,it's like maybe i should take wait and see stance fer now

  • Anonymous
    February 10, 2011
    I installed 971029 on a 64 bit Vista pc and after install it would not come back up. Booted in safe mode, uninstalled it and PC boots OK

  • Anonymous
    March 11, 2011
    Typical M$ arrogance  Make it a CHOICE. Let US decide how to setup autoplay when and as we want to CHOICE !! OUR way NOT M$'s ! "A function or feature without an on-off switch is just a bug that needs to be fixed by the addition of an on-off switch"

  • Anonymous
    May 14, 2012
    The comment has been removed

  • Anonymous
    January 26, 2014
    The comment has been removed