An Example of Why UAC Prompts in Vista Can't

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.
LONG CALLBACK CPlApplet( HWND hwndCPl, UINT uMsg, LPARAM lParam1, LPARAM lParam2 )
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:
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:
Symantec Security Response Weblog: An Example of Why UAC Prompts in Vista Ca... Page 1 of 3
United States
Partners About Symantec
Cart
Welcome
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
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:
Events
News
Search All of Symantec
> Enterprise > Security Response > Weblog > Windows Vista > An Example of Why UAC Prompts in Vista Can’t Always Be Trusted
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."
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 a few informative blog posts recently. First, in a blog titled "Running Vista Every Day!" Joanna Rustkowska pointed out some issues with UAC, one of them being a simple implementation bug in UIPI. This, I believe in part, resulted in Mark Russinovich writing his blog entry "PsExec, User Account Control and Security Boundaries." Joanna posted another blog, "Vista Security Model ? A Big Joke?" in response to Mark's blog post. And then followed it with "Confiusion (sic) About The 'Joke Post,'" which was a response to how journalists misunderstood her "joke post."