posted on August 25, 2009 by Bryant Zadegan
Once upon a time, a Microsoft employee said that UAC was designed to annoy people, thus encouraging people (and systems administrators) to bug application developers and get those developers to fix their use of resources in Windows. Well, it seems that one company actually went backwards, making its application more annoying than it used to be.
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.
posted on July 30, 2009 by Maurice
As those involved in the Windows 7 community may know, Microsoft has failed to fix a crucial flaw in the User Account Control feature of the operating system which allows a specific whitelist of applications to inject code that can allow any application to silently elevate. The code was released about a month ago as a proof-of-concept by Leo Davidson showcasing the flaw elevating a command prompt window using the whitelisted explorer.exe process.
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.
posted on June 12, 2009 by Bryant Zadegan
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:
- Always On
- Notify when programs try to change settings (give a warning with this option about the potential risk of compromise)
- 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.
posted on February 4, 2009 by Bryant Zadegan
(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.
Read More »
Follow Bryant on Twitter! 
