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:
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).
"Fronteira de segurança" (ou security boundary ) é alguma barreira pela qual código ou acesso não podem