Tuesday, February 20, 2007 8:31 AM
Symantec Security Response Weblog: An Example of Why UAC Prompts in Vista Can’t Always Be Trusted
An Example of Why UAC Prompts in Vista Can’t Always Be Trusted
People who have been following the not unexpected initial wave of security research with regards to Windows Vista will have seen three informative blog posts recently. The first, by Joanna Rustkowska is titled "Vista Security Model – A Big Joke?" This, I believe in part, resulted in Mark Russinovich writing his blog entry "PsExec, User Account Control and Security Boundaries." The post by Mark (and some Slashdot.org coverage) was then followed by another posting by Joanna titled "Confiusion (sic) About The 'Joke Post.'"
Joanna hit upon a something in this last blog stating, "Mark Russinovich - declared that all implementation bugs in UAC are not to be considered as security bugs." I recently had the pleasure of working with Microsoft Security Response on an issue I thought was detrimental to the trust placed upon UAC prompts. In Microsoft’s Technet document "Understanding and Configuring User Account Control in Windows Vista" they provide the following graphic:
Figure 1: The UAC decision flow chart
This shows the different types and colors of dialog boxes one can expect to see when using UAC. One assumes they made these different colors to encourage the user to make a more informed judgment when allowing an application to continue. We can see that the dialog boxes that are blocked have a scary red color, those which purport to be part of Windows Vista are a nice teal color, third party signed applications are a light gray color and, finally, unsigned third party code is a semi-scary yellowy orange. Even Microsoft’s own description of the flow chart talks about this:
"Applications are first separated into three categories based on the executable's publisher: Windows Vista, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows Vista determines which color elevation prompt to present to the user. The following illustration details the elevation prompt logic for corresponding levels of trust."
The issue I discovered was that the binary RunLegacyCPLElevated.exe, which is signed by Microsoft, ships with Windows Vista by default with a manifest that says it needs to run elevated and is considered part of the core operating system, could be abused. Abused in what way? Well, RunLegacyCPLElevated.exe is designed to provide backward compatibility by allowing legacy Windows Control Panel plug-ins to run with full administrative privileges. What’s the drama? I hear you say. The problem stems from the fact that RunLegacyCPLElevated.exe takes as one of its parameters an arbitrary DLL with a particular export. The DLL has to export the CPlApplet function, which is then called with a number of different parameters depending on the action being performed. The function prototype for CPlApplet is as follows:
LONG CALLBACK CPlApplet(
The problem with this is that the arbitrary CPL files can be written to areas of the disk that non-administrative users can write to. So the scenario would be:
• The user gets infected by malicious code running as a restricted user – Trojan or exploit are two likely vectors
• This malicious code drops a malicious CPL file to disk in a location that the restricted user can write to
• The malicious code then calls RunLegacyCPLElevated.exe with the malicious CPL as a parameter
• The user is presented with a UAC prompt that claims that Microsoft Windows needs to elevate permissions and not a third party application
• The user authorizes and the malicious code obtains administrative privileges
An example command line would be: RunLegacyRPLElevated shell32,Control_RunDLL "C:\Users\Ollie\Desktop\PrivEsq.cpl","Boof". The user would then be presented with the dialog box shown below:
Figure 2: Dialog box
Microsoft describes the teal color dialog box as "Blue/green background: The application is a Windows Vista administrative application, such as a control panel." So Microsoft is saying you should only see this if the application is part of Windows. While it is true that RunLegacyCPLElevated.exe is part of Windows, it is not true that the arbitrary DLL it loads and executes is. This arbitrary DLL is not in a trusted location on the file system and it doesn’t even has to be signed.
I went to Microsoft with this and was pointed to a document titled "Security Best Practice Guidance for Consumers." One of the key statements in this document is:
"It's very important to remember that UAC prompts are not a security boundary - they don't offer direct protection. They do offer you a chance to verify an action before it happens. Once you allow an action to proceed, there may be no easy way back."
So while Microsoft may use the word trust when in relation to UAC in some of their documentation with statements such as – "The following illustration details the elevation prompt logic for corresponding levels of trust." – in actual fact, even the data these UAC prompts provide you with can’t be trusted.
Unfortunately, this particular issue I discovered also has an unintended consequence on a security policy which may be used by enterprises. There is a security policy item called "User Account Control: Only elevate executables that are signed and validated," which is designed to ensure that only trusted code can be elevated. Well, unfortunately due to the same reasons the UAC prompt can be fooled, this security policy can as well.
In summary, Microsoft in some quarters talks about UAC and trust, in others about the users making a decision before it’s too late. Hopefully from this write-up, you can see that it becomes a chicken and egg situation when the user is making a decision based on a false sense of trust.
Do I think some UAC is better than no UAC? Yes. Do I think UAC that presents information that can not be relied upon is good for user confidence? No.
One final note, I believe there is at least one other executable in Windows Vista that will exhibit similar behavior to RunLegacyCPLElevated.exe. I believe Microsoft needs to start to take these a little more seriously than just pointing at best practice guidelines that have the same likelihood (not much) of being implemented or followed as telling people not to open arbitrary executables attached to emails.
Posted by Ollie Whitehouse on February 20, 2007 05:00 AM