Of course, I’m talking about Java.

I figured I would turn Java into an example of what not to do when designing something for Windows before uninstalling it. Since Sun Microsystems clearly has no idea how to develop for Windows Vista, I’m going to direct them to this wonderful page.

I highlighted the single switch present in the command which indicates the problem: “-auto”. UAC prompts should never be automatically launched without informing the user prior to launching one. It’s very plain and very simple, and when developers start writing applications which throw consent prompts without any obvious reason as to why, they’re clearly doing something wrong.

Worse yet, Java Automatic Update decides to tell me after I click Cancel that it wants to update.

This bubble should be thrown first, followed by launching the consent prompt should the user decide to update. Doing it the other way around is mindblowingly stupid. It’s not exactly an easy thing to screw up, either, so I’m chalking this one up either to developers not knowing what they’re doing or developers testing UAC out for the heck of it to see how many people obey random UAC prompts.

If you’re seeing this, I highly encourage you to click Cancel. Better yet, go ahead and uninstall Java. That’s what I did.

Now if you’ll excuse me, I’ll be going off to celebrate my birthday away from random UAC prompts.

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: added a link to the original exploit

I really, really hate having to interrupt a good series bashing Apple, but this has to be said.

Long has resumed his crusade on fixing UAC, and normally, I would tell him to give it up for the sake of saving his own time. However, even though Mark Russinovich might not see UAC as a security boundary, the original UAC team sure as hell did, which makes me want Long to see this all the way through. (check the sidebar on the left)

“User Account Control (UAC) is a core security feature in the next release of Windows Vista and Windows Server code name Longhorn.” –UAC Blog

Guys, just fix it. I don’t see why things have to be made so hard; the UAC team clearly calls it a security feature, so do them a favor, don’t make them feel like they’ve wasted their time, and fix the problem. Thanks, Long, for telling me that this can’t actually be fixed as it’s a design issue, so here’s a better solution: give the user the ability to chose which UAC setting he/she wants upon first run. Here are three good options:

1. Always On
2. Notify when programs try to change settings (give a warning with this option about the potential risk of compromise)
3. Always Off (give a bigger warning with this option)

You’ll notice that I didn’t actually suggest the option which gets rid of the secure desktop: I personally believe that that particular option offers absolutely no benefit over having UAC off altogether.

I figured it had to be said.

(If you want to take this for a test run yourself, check Leo Davidson’s site for the original source code and binaries for the proof of concept exploit)

Mark & friends, I love you guys dearly, but I’ll be taking the original team’s word on this one. If you guys try editing it out, keep in mind the Internet Archive has a copy of the original statement.

(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