The company stands by UAC in its final form, but they’re taking it a step further by blocking the program that causes the exploit using their own security software.

Today, I just happened to download the zip file that causes the exploit when Microsoft Security Essentials greeted me with a nice dialog telling me that what I just downloaded is malware, specifically HackTool.Win32/Welevate.A and HackTool.Win64/Welevate.A (depending on architecture). While I’d agree that this can be considered a form of malware, it’s just a very bad way of dealing with the situation. However, Leo noted that Windows Defender in Vista did not detect this exploit, and Bryant confirmed that the same is true for Windows 7 (where the trick would actually work), so this seems to be exclusive to Microsoft Security Essentials.

It’s not clear what method the signatures take to detect it, but I promptly recompiled the source code under the Visual C++ 10.0 toolkit using VS 2010 Beta and the application ran undetected. Not a very good solution if it actually hash checks for the specific applications.

Leo, and I (or Bryant) will update our respective pages accordingly as we discover more. Bryant is seeking official word from Microsoft on what’s going on. Meanwhile, you can see the VirusTotal report here and grab the exploit here.

Update (~Bryant): let’s take a look at what’s going on here from a different approach. Microsoft says that the vulnerability here is not actually a vulnerability and is, in fact, by design. However, they’ve also classified Leo’s proof-of-concept as malware. Logically speaking, if a process whose sole purpose is to exploit a perceived vulnerability is marked as malware, then it’s reasonable to assume that the perceived vulnerability is indeed a significant problem. Basically, Microsoft contradicted themselves by listing the proof-of-concept as malware.

Update 2 (~Bryant): A friend of mine proposed one particular argument as a potential explanation to this issue, whereby this is a bug within Microsoft Security Essentials. The reasons I don’t believe this to be the case are:

• This exploit was specifically named as HackTool:Win32/Welevate.A (A quick googling shows only three links; one is to the aforementioned virustotal link, the second and third to a Microsoft encyclopedia entry.
• This particular label only applies to this specific proof-of-concept
• A reasonable vulnerability assessment (”Medium”) was applied to this particular proof-of-concept, which makes sense given that this security vulnerability in UAC is only really an issue if either a user runs a malicious application or if some other internet-facing application were to be compromised. I covered the latter in an older post of mine where I explain how this flaw essentially raises the vectors of attack many-fold.

Leo and Bryant contributed to this post.

(Update: official statement appended to the end of the post)

I’m going to open this post by kindly asking you, the user, to go into the Windows 7 Action Center (Control Panel, System and Security, Action Center), clicking “Change User Account Control settings” and setting it to the maximum setting (“Always notify me when…”).

The reason for why I’m asking you to do this shouldn’t be a surprise. You may have seen the UAC posts by Rafael Rivera and Long Zheng (I’m giving more of the credit to Rafael since he actually brewed the proof of concept code). People saw their posts and immediately assumed that this issue is only relevant for users who download malware. Thus, you hear lots of users saying out loud with no apparent fear of embarrassment:

“La di da, so long as I’m not stupid with what I download, I should be fine!”

Right. Well, Microsoft basically recommends for users to install an antivirus because they don’t actually consider User Account Control to be a security feature. Anyone who knows the purpose of privilege management knows that any system which actively manages privileges is a security feature.

With this in mind, let’s take a look at why the UAC security flaw actually is a security flaw.

Update 2: Steven and Jon posted a second post about UAC today specifically addressing this flaw. Catch their response below the break.

The goal of security engineers is to minimize the number of attack vectors. That way, the likelihood of a path of attack opening up is slim. This also allows for security engineers to kill the attack vector until a patch is released for the vulnerable application or component.

So, before actually continuing this post, lets quickly answer this question: What’s a silent attack vector? Basically, if there exists a path for malicious code to quietly hijack a computer (to hijack a computer without the user’s knowledge), it’s a silent vector of attack.

In Windows Vista, attacking a user-mode app isn’t going to completely fry your system. At the most, that one user account might be roasted, and this is easily fixed by logging into the default Administrator account and creating a new account from there. Any attacks which try to slam kernel-mode resources trigger an immediate UAC prompt as a last minute defense, which a user can simply deny, thus blocking the attack.

Mind you, if a malicious bit is determined, it can keep spamming you with UAC prompts if you click No, and you’ll have a hard time bailing out of them to resume your work, but even then, it’s only isolated to one account so long as you keep denying it. Just kill the power to the computer, reboot into the default Administrator account and create a new account for yourself.

Now that we’ve discussed why UAC is actually useful in Windows Vista, here’s the problem with Windows 7’s default UAC setting:

If a security hole is found in any user-mode application, that application can be infected and used to silently attack the system through keystrokes used to disable UAC when the user is away from the computer. This is, of course, why I call this security flaw an Exponential Silent Attack Vector Multiplier.

No matter what the application is, since keystrokes can be faked on explorer due to its “medium integrity” level of trust, any attack vector available through any application, process, what have you, can now be used to deliver a malicious payload which can completely take over the entire computer as opposed to just one user account.

It’s not just about what a user clicks anymore. All of a sudden, Windows 7 is now at risk from drive-by downloads in any browser, buffer overflow bugs in any application, or any other way of seamlessly delivering and executing a simple script to emulate keystrokes. Quite literally, the number of attack vectors increases with the number of applications installed.

• Got a .psd file which takes advantage of a flaw in Photoshop? There goes Windows.
• Got an .odf file which takes advantage of a flaw in WordPad? (Yes, WordPad, since it can also open ODF files) There goes Windows.
• Got an IM client which renders jpegs improperly and someone’s display icon contains an exploit? There goes Windows.
• Got a browser which is susceptible to drive-by downloads? There goes Windows.
• Got an mp3 which exploits a hole in Windows Media Player? How about a stream with malicious content which exploits a hole in QuickTime? What about a malicious podcast feed which can bust through the Zune Software or iTunes? There goes Windows.

The list of examples isn’t limited to the list above. Prior to this new “non-invasive” UAC, the number of silent attack vectors was limited to any flaws in elevated Windows components. Thanks to this flaw in UAC, the number of attack vectors is now effectively limited only to the number of vulnerabilities in applications available for Windows. (read: way more than in Windows alone)

What’s the important thing to learn from this? If it can be executed and has a exploitable hole, thanks to this flaw in UAC, it can serve as a vector of attack.

This flaw is so ridiculously and utterly bad that it brings us right back to the times that people used XP with an unprotected administrative account. This essentially negates any benefit that UAC gives to the user.

Solution for the end user? Well, like I stated when I opened this post, max out UAC on Windows 7 the immediate second you finish installing it and do not connect Windows 7 to the internet until you do. Yes, you should be that paranoid; this flaw needs to be resolved immediately. If this really is by design, Microsoft screwed up.

I can’t wait to hear the explanation for this one. I love Windows 7, but when a team closes a report on a critical demonstrated security bug as “by design,” I don’t know what to think.

Update: For now, an official Microsoft spokesperson gave the following exact statement regarding the issue: “We’re investigating and continue to thank everyone who provides feedback on the Windows 7 beta.”
Look out for an update to this issue… hopefully soon. I know Charles Torre of Channel 9 fame had a UAC interview planned, but I don’t know where that went.

Update 2:

With this feedback and a lot more we are going to deliver two changes to the Release Candidate that we’ll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. That was already in the works before this discussion and doing this prevents all the mechanics around SendKeys and the like from working. Second, changing the level of the UAC will also prompt for confirmation.

Source: E7

On the other hand, the systems which are not supposed to crash are the ones which are associated with bug reporting, user experience improvement, et cetera. So, when said utilities crash, what do you do?

Chris Holmes, a mutual friend of mine and Rafael, recently discovered (along with Rafael) the source of a round of interesting crashes in Windows 7 Beta 1. The bug itself is uninteresting and typical; besides crashing virtually anything running on top of a Windows service which calls the SQM client (a part of the CEIP), it’s nothing big. What interests me the most is that this bug is triggered when the Customer Experience Improvement Program is running.

Catch my abnormally detailed reasoning after the break.

Update: The Windows Team pushed a nicer solution to the Action Center. The solution may need to be re-used every once in a while as disabled sessions accumulate, but it’s better than killing the CEIP outright. Catch more at the end of the post.

Quite possibly one of the most important things to check prior to releasing any beta, minus the critical bugs, are the reporting mechanisms. When those don’t work, a number of issues arise:

1. One or more massive avenues for feedback are now out of The Game, which means less feedback for Microsoft. Jensen Harris discussed with me a while back how critical the Customer Experience Improvement Program was to the success of the Office Ribbon, so losing such an avenue in a milestone build can only be seen as a dramatic loss of resources.
2. Confidence in the build begins to drop. Sure, this is a beta, and as such, it’s acceptable for just about anything to be slightly unstable. However, as I noted earlier, stability is expected if not demanded in the reporting tools. When those fail, what’s to say other elements critical to testing the beta won’t fail as well? Beta means “there could be bugs” but it doesn’t mean “there could be bugs with the tools you’ll need to report the bugs!” Confidence in the “testability” of the build could tank as a result.
3. Once word spreads, the more dedicated beta testers will have to disable the CEIP module in order to proceed with testing other critical components. This means that any user experience quirks may have to be reported manually as opposed to CEIP data being intuitively interpreted to determine where said UX quirks lie. This eats valuable tester resources, though I guess it doesn’t matter given that the beta program itself is being devoured from the inside out by the arrogance of the testers within it. (Paul Adare, I’m looking at you)

The fix? Well, Chris already published one, but Microsoft needs to get CEIP in Windows 7 back up and running as soon as humanly possible. The more people disable the CEIP for the sake of avoiding this bug, the less feedback Microsoft will get and the less potential Windows 7 will have to be the best that it can be upon launch. Sure, it should be fixed just to resolve the MSIExec issues, but that’s not the biggest reason to fix the crashes. After all, the definition of irony is when something designed to avoid a particular outcome actually causes the same outcome. In this case, no tool designed to improve user experience should ever serve to ruin it. Otherwise, the end result will show on your consumers’ faces:

He’s not a happy camper, but then again, it’s not as if other platforms are immune from stupid usability bugs. Thanks goes to our codemonkey Sam for taking this screenshot from Leopard while trying to access the link to Chris’s fix for the SQM client bug on Windows 7.

Until this is all resolved, if you’re a beta tester (edit: and you’re seeing this bug occur), please kill the CEIP in Windows 7 and proceed to report any UX quirks you run into through the submit feedback tool next to the minimize button in the titlebar of every major window. Do NOT use the Windows 7 taskforce. Both Larry Osterman and Brandon Paddock agree that the Windows 7 Taskforce is NOT the appropriate way to submit bugs!

Update: Chris updated his blog with another post that notes the presence of the fix to the problem in the Windows 7 Action Center (the solutions page you reach when you have a crash that Windows can look up and find a solution for). The Action Center simply has the user kill the DisabledSessions key without killing the customer experience improvement program, so disabling the CEIP is no longer a necessity it seems.
Unfortunately, I suspect that this is only a temporary fix, given that the problem originally appeared after some time had already passed with Windows 7 running on a number of end users’ boxes. With this in mind, this process will still likely need to be repeated any time the key is created and filled with any values in order to avoid MSI-based installers from failing yet again.