grand stream dreams: Speak of the devil: Norton’s UAC Tool

Saturday, October 18, 2008

Speak of the devil: Norton’s UAC Tool

As I have seen mention, Vista’s UAC is being tweaked a bit in Windows 7.

TechBlog: Microsoft reworking the UAC for Windows 7

Dwight does a great job summing up the pains and protections that it offers as well as looking at the promised granularity that Windows 7 hopes to deliver to UAC.

In the meantime, Vista users have had a handful of options available to them with UAC control and tuning;

Do nothing and learn to love it. It does protect the system and if applications were written correctly (per Microsoft’s line) then UAC shouldn’t be the bother it is reported to be.
Disable User Account Control in Windows Vista – Not recommended by either Claus or most other Microsoft or Windows techies, but certainly possible.
Modify the prompting system slightly using the TweakUAC for Windows Vista free utility. This is what I have done and I find it provides a good balance between security and usability.

Now, that beloved flagship of security software has rocked the boat with a new beta product:

Norton UAC Tool – Norton Labs Vista User Account Control utility

(image capture from Chron.com Techblog post)

The Tool

What this little dude does is two-fold:

First it changes the alert notification window for UAC and make it a bit more “useful” in information provided. Note that you can expand the notification window to view the properties of the object and if it is digitally signed and in a protected location. Those are two factors that are good (but not perfect) indicators the software is safe to execute.

Second, it allows a “Don’t ask me again” option so once you have vetted the UAC prompt “Allow” or “Cancel” you won’t be prompted again as you have given implicit permission to execute again in future encounters. Think of it like setting your firewall filter rules for allowed connections. Similar concept.

And to be clear, it does report the user’s UAC option selections back to the Symantec mothership for “data-gathering” purposes. FYI.

More details here:

Norton UAC FAQ – Norton Labs
Vista users: Why wait for Windows 7? Get a better UAC now – TechBlog with Dwight Silverman
Norton Takes on Vista’s User Account Control - SuperSite Blog

As Shaun with Symantec commented on Dwight’s blog post, there is an important detail to know. The “always allow” are contextual based. In that they will only allow for the specific location and method of execution, not based on the target being launched alone. That’s pretty good.

The Norton UAC tool allows an application to run with silently-elevated privileges only in a specific context that was previously approved by the user with the "don't ask again" check box selected.
This means that there is a difference between regedit.exe launched from the start->run box, regedit.exe originating from a shortcut double click, and regedit.exe launched from a double click on a .reg file (and the context actually changes with each .reg file), and regedit.exe being launched by an application (malicious or not).
Given the contextual awareness of Norton UAC tool's automatic answering, the Norton UAC tool provides a usability improvement over Vista's default UAC prompts, while maintaining obvious security improvements in the Vista kernel (such as isolation, file/registry virtualization, and user interface privilege isolation) that are all disabled when UAC is disabled.
We decided to write this tool after we noticed two alarming trends with UAC. The first is that users fully disable UAC - which is a horrible workaround to a minor usability issue (since it disables isolation and virtualization - which in turn removes IE's protected mode). The second is that users get so used to responding to UAC prompts with "allow" that the prompts are often not even read by the user (Chicken Little "the sky is falling syndrome).
As a result, we are collecting information on the subject matter of prompts in addition to the response times to determine if reducing the overall number of prompts (by allowing users to remember their answers) causes users to spend more time reading the prompts... Microsoft records very similar timing and response information for all of Vista and Office when you agree to take part in the Customer Experience Improvement Program.
As for the impact to your system, the Norton UAC tool produces no running processes and is only active during a UAC prompt. We worked very hard to ensure the Norton UAC tool as as fast or faster than the built in Vista UAC prompts.

The Method

This alone is pretty cool, although I’m not feeling a need to swap it out with my TweakUAC solution just yet.

However, fortuitously I was able to discover some research done by clever Windows examiners on just how the Norton UAC Tool appears to be working.

In the comments on Paul’s blog post were links provided by a Chinese Windows dude. Pointed to two posts that provides some background on what Norton's is doing to fuzz the UAC system.

I'm linking to the Google-Translate version pages. However it still leaves a bit of the technicals "lost in translation" if you will.

Vampire in mind: an in-depth realization of the principle Norton UAC Tool - Smallfrog's Technical Blog.

Norton UAC Tool theory analysis - Asuka's Blog

Looks like the tool executes the “symconsent.exe” process which does an intercept point (hook) to the official UAC executable “consent.exe”. According to Smallfrogs, when UAC is triggered, Vista attempts to load UAC’s consent.exe file. Norton’s UAC tool installs a filter driver file called “SymARF.sys”. That one intercepts the Vista UAC image file call and does a load image of the “symconsent.exe” instead. Based on the user’s response to the Norton UAC prompt intercept, the choice/data get logged (and reported) and set up for next time handling (if requested) and turns operations back over to “consent.exe.”

If the “cancel” option is chosen, then a new/different “symconsent.exe” process gets fired off to create the XML handling rule document that Asuka points out in his post.

I know this probably isn’t entirely accurate, but I haven’t had the time to either learn Chinese myself and the translation is a bit gunky, nor have I had time to load it all up on my own test-bed to observe and make notes.

However, this should be close enough of a process handling description for now to get the gist of it, and certainly one could replicate their results to figure it out on your own.

I’m really curious as to what Mark Russinovich might have to say.

Dangers?

Certainly curious stuff. And if Norton's can pull it off, could Norton's tool be compromised as an attack? Could other attacks be created based on this technique? How is the integrity of the tools XML handling file maintained and prevented from being hijacked by malware like the HOSTS files often are?

Paul’s post comments also have these strong and insightful thoughts (with which I am agreeing) as posted in a series by PatrioutB6007 (a.k.a. Mike Galos):

PatriotB6007
"Don't ask me again" is a very dangerous feature which leaves your system wide open for elevation of privelege attacks. As I commented on a ZDNet blog yesterday:
>>>
The problem with "don't ask me again" is that the system has to know that *you* specifically are the one taking the action requesting the prompt. I'm curious if these Symantec prompts make any attempt to determine this, otherwise it's a giant elevation of privelege hole.
Let's say there's an unpatched code execution vulnerability in my web browser and I go to a site that tries to exploit it. My browser runs at low integrity (IE) or regular/medium integrity (Firefox), and so I know that any exploit can't do anything administrative without my permission because a UAC prompt would need to appear first.
However, what if they try to launch something that I'd already said "don't ask me again" for? Is Symantec smart enough to know that the request didn't really come from me? It's really, really hard to determine the difference between the exploit case and a legitimate case.
talkback.zdnet.com/5208-12554-0.html
<<<
A reply from "davewood [MS]" (Microsoft employee it would seem) agreed, and mentioned that this also opens the door for application installers to pre-mark the apps they install in the "don't ask" category.
This enables the following elevation of privelege attack:
1. I run the installer for app XYZ.
2. The installer marks XYZ as "don't ask".
3. An attacker discovers upon two exploits, one in my web browser and one in XYZ.
4. I stumble upon a malicious site which uses the browser exploit to cause my browser (which is NOT running as admin) to launch XYZ.exe, feeding it specifically-formed data e.g. via a command line parameter of a file or URL to open.
5. XYZ silently elevates to Administrator, and the malicious data hits the vulnerability in XYZ and causes the attacker's code to run, with full administrative privileges. Pwned.
October 11, 2008 4:10 AM
PatriotB6007
Exactly right.
It isn't as though the people at Microsoft didn't think about "mark this as safe". It's an obvious optimization. The problem is that it's also an insecure optimization.
Maybe Symantec has some really neat trick behind the covers that solves the problem.
Maybe.
But, nothing on their site suggests that they have. And that makes this tool potentially a serious security hole.
October 11, 2008 8:33 AM
PatriotB6007
It's actually even worse than that. In the example, if app XYZ is Internet aware as most apps are these days then you don't need a vulnerability in both the browser and XYZ.
You could have the case where XYZ phones home for an update and the XYZCorp update server has been spoofed (say a man in the middle attack). The XYZ app updates itself with the exploit with no prompt (the goal of the Symantec app) and now runs the exploit code.
So far, this wouldn't be something that UAC would have saved you from since you were expecting the update so you'd have said OK anyway. The problem, though, is that now the pwned XYZ is running the exploit with Admin privs and is able to do lots of evil nasty stuff with no UAC prompts to let you know that the app has been hijacked. This is where UAC would normally prevent damage but the "don't show again" neutered UAC happily lets the pwned app destroy your system without warning.

Maybe Shaun with Symantec has some additional information on this and the degree of intelligence and granularity with application launching by their tool. His comment certain seems to suggest that they have considered this.

My question is just how deep and discretionary is their tool able to go? Is their tool able to correctly intercept all UAC prompts to a previously approved activity if it is bot-based or malicious script based?

Microsoft really locked UAC down and implemented it for a reason.

It’s just curious that a security company is doing an end-run about it in the attempt to make it a more-secure “experience” for end users.

More useful UAC bits from Ed Bott here: