Improvements to AutoPlay

re: Improvements to AutoPlay

Nehemoth — Tue, 28 Apr 2009 06:24:50 GMT

Nice job, as always.

Keep the information.

W7 best OS from Microsoft Ever.

re: Improvements to AutoPlay

RyGuy12 — Tue, 28 Apr 2009 07:07:23 GMT

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!

re: Improvements to AutoPlay

Xepol — Tue, 28 Apr 2009 07:28:55 GMT

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?

re: Improvements to AutoPlay

soumyasch — Tue, 28 Apr 2009 08:02:40 GMT

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.

re: Improvements to AutoPlay

Domenico — Tue, 28 Apr 2009 08:03:11 GMT

Nice nice nice JOB !!!

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

Go Team !!

5 May coming soon

re: Improvements to AutoPlay

Kein — Tue, 28 Apr 2009 09:10:48 GMT

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...

re: Improvements to AutoPlay

mludwig — Tue, 28 Apr 2009 09:36:44 GMT

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.

re: Improvements to AutoPlay

Asesh — Tue, 28 Apr 2009 13:01:21 GMT

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 :)

re: Improvements to AutoPlay

someone — Tue, 28 Apr 2009 13:35:49 GMT

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?

re: Improvements to AutoPlay

Jalf — Tue, 28 Apr 2009 14:22:52 GMT

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)

re: Improvements to AutoPlay

acaldwell@live.com — Tue, 28 Apr 2009 14:46:45 GMT

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.

re: Improvements to AutoPlay

krsanford — Tue, 28 Apr 2009 15:44:38 GMT

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.

re: Improvements to AutoPlay

wolrah — Tue, 28 Apr 2009 19:59:08 GMT

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.

re: Improvements to AutoPlay

Tihiy — Tue, 28 Apr 2009 22:03:55 GMT

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.

re: Improvements to AutoPlay

manicmarc — Tue, 28 Apr 2009 23:54:20 GMT

"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?

re: Improvements to AutoPlay

Don Reba — Wed, 29 Apr 2009 04:02:08 GMT

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.

re: Improvements to AutoPlay

Xlfdll — Wed, 29 Apr 2009 07:25:46 GMT

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.

re: Improvements to AutoPlay

kaiwai — Wed, 29 Apr 2009 12:04:45 GMT

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.

re: Improvements to AutoPlay

limulus — Wed, 29 Apr 2009 16:38:38 GMT

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).

re: Improvements to AutoPlay

Xepol — Thu, 30 Apr 2009 00:04:00 GMT

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.

re: Improvements to AutoPlay

cyberdrop — Thu, 30 Apr 2009 01:32:42 GMT

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.

re: crippling AutoPlay

davidmahaffy — Thu, 30 Apr 2009 01:36:54 GMT

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.

Response to feedback

arikc — Thu, 30 Apr 2009 02:43:44 GMT

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

Signature requirements

MikeMS — Thu, 30 Apr 2009 04:53:58 GMT

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

Optical discs are historically an attack vector

mechBgon — Thu, 30 Apr 2009 05:18:59 GMT

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.

re: Improvements to AutoPlay

limulus — Fri, 01 May 2009 09:25:40 GMT

@ 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.

re: Improvements to AutoPlay

phongm — Sat, 02 May 2009 00:11:42 GMT

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

re: Improvements to AutoPlay

gabsoftware — Sat, 02 May 2009 07:16:09 GMT

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 !

sorry about the OFF

lyesmith — Sat, 02 May 2009 12:29:00 GMT

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.

re: Improvements to AutoPlay

SwooshyCueb — Mon, 04 May 2009 00:55:55 GMT

This interferes with Ceedo. WHYYYYYYYYYYYYYYYYYYYY? I LOVE CEEDO!

PROPOSAL: Use Signed Code For a Better Solution

John T. Haller — Tue, 05 May 2009 20:00:12 GMT

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/

"Improvements" ...really!? (+PROPOSAL)

Duggeek — Thu, 07 May 2009 19:18:08 GMT

This has been a part of Windows functionality for over a decade. While a few mal-ware proponents have taken liberty with Autoplay and Autorun functionality, many more actual customers and users have found it a boon.

I agree that security and having confidence in the Windows environment is paramount, however it just seems like you're "throwing out the baby with the bathwater" here.

The Dev Team sure is proud of their "deep insight" features, why not apply that same thinking to AutoPlay? In the dialog, add visual indicators regarding the validity (digital sig's anyone?) of the executables. Your illustration--with the red and green outlines--seems to be an excellent start; why not grow on that concept?

"Spoofs" are easy to detect, since they are mocking the appearance of the UI defaults... we don't even need WinDefender to check it, it's obvious because it's a copy-cat!

(Nodding to others in the thread) Regarding selective AutoPlay actions with respect to individual media; for anyone that works with more than 10 different removable drives in the course of a day, picking specific behavior for each drive could surely be a boon. Moreover, eliminating AutoPlay framework for removable/re-writable media would impact a significant portion of IT professionals that have crafted independent (sometimes ingenious) solutions around that framework.

AutoPlay was conjured-up in the age of the CD-ROM... well before the advent of flash-memory media. 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.

Re-consider this move; have you really come all this way just to axe an idea that was introduced before its time?

re: Improvements to AutoPlay

vicza — Wed, 13 May 2009 19:57:11 GMT

It's good that you have removed AutoPlay, but could you please also return the option "Do nothing" in this windows? It was in Win XP. Theoretically, there also was a possibility to remember this choice (did not work always, though). But not in Vista, nor in Win 7. Why? It's *terribly* annoying. Why I insert my flash drive I do not want _any_ windows to appear. Return this option, please.

Signed applications

Soon Bing — Fri, 22 May 2009 13:38:17 GMT

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?

re: Improvements to AutoPlay

k0b033 — Fri, 29 May 2009 22:38:36 GMT

Here's a pretty simple idea that I'm surprised no one has mentioned yet.

Why don't you just disallow anyone from creating an AutoRun/AutoPlay option that is named "Open folder to view files"? (or other variants/languages)

Prevent ASCII or those ALT+keypad codes or any other workaround, and that should reduce the chances of anyone mistaking file execution from file viewing.

re: Improvements to AutoPlay

mucs — Mon, 01 Jun 2009 06:02:35 GMT

For me, it would be nice if there's an option to run anti-virus scan on autoplay.

re: Improvements to AutoPlay

Thesis Help — Sat, 13 Jun 2009 11:55:07 GMT

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.

re: Improvements to AutoPlay

GCSE Coursework — Sat, 13 Jun 2009 11:56:25 GMT

re: Improvements to AutoPlay

Paddy Power Free Bet — Thu, 25 Jun 2009 03:06:44 GMT

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.

Autoplay for blind people

laurentz — Wed, 01 Jul 2009 11:52:19 GMT

As limulus mentioned, it will break some software, like for instance a usb stick (with CDrom partition)which launches a screenreader for blind people. Under XP, when the user plugs the USB stick, the software is automagically launched without further action, so even a blind people can run it. Now, under W7, it will require the user to click a button... err remember, he's blind !

What do you suggest ?

We cannot require that his computer (potentially it could be a public computer) is preconfigured to "always run" the software from CD.

re: Improvements to AutoPlay

deemon@gmail.com — Mon, 16 Nov 2009 04:07:50 GMT

The biggest and easiest improvement to the AutoRun/AutoPlay feature would be an easy and reliable way to turn it off completely. This feature is hugely annoying and a security hole, why is there no checkbox in the control panel to do ABSOLUTELY NOTHING when a new drive is connected? Like, completely and absolutely, no exceptions, no content handlers, no autoinstalls, no nothing. When it's not possible, I feel that I am simply not in control of my own PC, and this absolutely sucks and makes me want to install Ubuntu.

I don't want the Windows Explorer to hand-hold me, just don't look into my disks until I've told you to, how hard is that? On the Vista, you have to install a patch to be able to disable it, can it get any worse? Why am I not in control of my own PC?

re: Improvements to AutoPlay

blu ray ripper — Sun, 29 Nov 2009 05:22:35 GMT

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