So Ollie over at Symantec has done a good job in this blog post summarizing some of the scrutiny Vista's UAC has come under recently from various security researchers:  http://www.symantec.com/enterprise/security_response/weblog/2007/02/an_example_of_why_uac_prompts.html

Ollie responsibly disclosed the issue he describes in the above article to us and then blogged about it when we replied that this was not a security vulnerability that needed to be addressed in a security bulletin.  I have no problem with that . . .

For those who don't want to read all of the blogs surrounding this - here's the high level overview of what's going on here with the Symantec finding:
Ollie has discovered that one could create a malicious DLL that is coded up like a control panel applet (a .CPL file) and that person can then run an executable built-in to Vista (RunLegacyCPLElevated.exe) which always requires elevation (thus it will always trigger the UAC prompt) that will in turn load this DLL into the elevated host process.  He posits that one could drop this malicious file in a user writeable folder (i.e. the users local my documents folder or IE TIF folder) somehow and then at the same time one could also cause this Microsoft signed EXE to run, somehow, passing in the path to the malicious DLL (.CPL file) and when the UAC dialog comes up - the user would think they are running a valid Windows EXE (because they are!) and they will get the 'less scary' UAC dialog (since the EXE is signed by Microsoft) vs. the 'more scary' dialog they would get if they were attempting to run an un-signed binary.

All of this is true!

But does it really matter and is this a security vulnerability?

Here are the facts surrounding this attack:

1. The bad guy first has to get the binary written to a part of the disk a non-elevated user can write to - this is not a trivial task - especially with IE running in protected mode (assuming IE to be the most likely attack vector here - there's only one folder IE in protected mode could be coerced to writing too if it were hit with a remote code execution 0-day and that's the "C:\Users\USER\AppData\LocalLow" folder since IE by default runs at low integrity level and that's the only folder marked with low integrity by default.  In reality in the absence of a good IE 0-day and due to the integrity level restirctions - the bad guys would probably just social engineer the user to get them to save the file without using an IE 0-day.  Let's ignore the social engineering and let's assume IE is coerced into dropping the malicious CPL file in the 'LocalLow' folder.
2. The malicious CPL which is now in the LocalLow folder would need to be passed in as a parameter to the RunLegacyCPLElevated.exe which would have to be called as part of the exploit - so the exploit code has to first save the file to a writeable folder and then call RunLegacyCPLElevated.exe.  At this point the user would then be prompted with a teal/blue/green "good" UAC dialog box (instead of the scarrier orange/red dialog box) and if they allow the Vista EXE to elevate - then the malware CPL file will run with elevated administrative permissions - if the user doesn't allow the UAC dialog then the exploit stops here.  I'm assuming the exploit page would encourage the user to accept the UAC elevation and Ollie's point is since this UAC dialog is the teal/green 'system' dialog - users would be fooled into elevating the malware.

So to summarize - if a code execution bug in IE is found that allows for the arbitrary creation of files on the users disk - they can only drop the malicious CPL in one folder and then to run it elevated they would cause IE to call "RunLegacyCPLElevated.exe" and pass in the path to this newly created .CPL file which would then give the user the teal/green UAC dialog box vs. the orange one.  If they used social engineering they would probably likely get the user to save the CPL and a batch file (together - the batch file would call RunLegacyCPLElevated.exe and pass in the malicious CPL) or just an EXE that extracts the CPL and calls RunLegacyCPLElevated.exe and then ask them to run the batch file or the EXE . . . this would then give them the teal/green UAC dialog instead of the orange one.

So really what this 'exploit' amounts to is getting malware to throw up a teal/green UAC dialog vs. an orange UAC dialog.  Yes, that's right - all this fuss is over the color of a dialog box . . . a dialog box the user can still choose to dismiss without allowing the malware to run (in both cases).  They have not found a way to bypass the UAC dialog box entirely and to run the malware elevated . . . they have simply found a way to change the color of the dialog box by taking advantage of an EXE built-in to Windows for the purpose of running legacy control panel applets - of which there are many in existance.

Now - at this point I have to ask . . . does this attack really matter?

I have already witnessed first hand - Microsoft employees being socially engineered on Vista and tricked into elevating malware applications (in this case it was a fake Valentine’s day e-greeting that tricked an employee into elevating an 'Adobe Flash' installer that really wasn't the Adobe Flash installer).  Internet Explorer should have prompted the user first to open or save the EXE after he clicked a link to 'install Flash' . . . the user probably chose to 'Open' the EXE directly from the Internet which caused IE to download the binary to the TIF (Temporary Internet Files folder) and then run it right away . . . the user would have THEN gotten a dialog box from the Attachment Manager API about running things from the 'Internet Zone' which he would have had to acknowledge (another chance to 'cancel or allow') . . . then the UAC dialog popped up (I know this from the event log audit trail) and since the EXE wasn't signed (I'm guessing) he would have gotten the scarrier orange dialog box (another cancel or allow) - which wasn't enough to deter this employee from getting Stallown3d as he still allowed the un-signed random EXE he just downloaded from the Internet to run elevated even though UAC and IE (via Attachment Manager API) told him it was a bad / risky thing to do and gave him a chance to cancel.  Hey - it's Flash right?  People trust Flash.  And he needed a newer version of Flash to see the greeting card and Adobe releases a new version of Flash like every other week so its very plausible the version he had installed was out of date and that he should update. 

My point is - this attack highlighted by Symantec, in the greater scheme of things just doesn't matter - it's not needed in order to fool people into running malware today.  Even with UAC and its nifty color coding - the average PC user is still not really cautious enough about what they run to make trust decisions off of the *color coding* of a dialog box.  There is so much un-signed code on the Internet today from legitimate vendors that the average user is likely to encounter the orange dialog box many times during their adventures across the 8th dimension . . . so why go through all of the trouble Ollie has gone through to get your malware to run elevated with a green/teal UAC prompt instead of an orange one - when you can just successfully socially engineer > 90% of the Internet population running Vista and get them to run your malware with the orange prompt by telling them it's Flash??

Finally - do you really think we would use *color coding* as a security boundary or claim it was one?  I mean c'mon folks - seriously.  It's *color coding*.  We're making an effort here to *try* to help you make a decision about the software you run elevated . . . there's no way this could ever be a security boundary in the same way that ohhh say an ACL is . . . or a window station (user session / desktop).