People who have been following the notunexpected initial wave of security research with regards to WindowsVista will have seen a few informative blog posts recently. First, in ablog titled "Running Vista Every Day!"Joanna Rustkowska pointed out some issues with UAC, one of them being asimple implementation bug in UIPI. This, I believe in part, resulted inMark 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."
Joanna hit upon a something in this last blog stating, "MarkRussinovich - declared that all implementation bugs in UAC are not tobe considered as security bugs." I recently had the pleasure of workingwith Microsoft Security Response on an issue I thought was detrimentalto 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 canexpect to see when using UAC. One assumes they made these differentcolors to encourage the user to make a more informed judgment whenallowing an application to continue. We can see that the dialog boxesthat are blocked have a scary red color, those which purport to be partof Windows Vista are a nice teal color, third party signed applicationsare a light gray color and, finally, unsigned third party code is asemi-scary yellowy orange. Even Microsoft’s own description of the flowchart talks about this:
"Applications are first separated into three categoriesbased on the executable's publisher: Windows Vista, publisher verified(signed), and publisher not verified (unsigned). The following diagramillustrates how Windows Vista determines which color elevation promptto present to the user. The following illustration details theelevation 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 witha manifest that says it needs to run elevated and is considered part ofthe core operating system, could be abused. Abused in what way? Well, RunLegacyCPLElevated.exeis designed to provide backward compatibility by allowing legacyWindows Control Panel plug-ins to run with full administrativeprivileges. What’s the drama? I hear you say. The problem stems fromthe 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 onthe 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 writtento areas of the disk that non-administrative users can write to. So thescenario 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 MicrosoftWindows 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/greenbackground: The application is a Windows Vista administrativeapplication, such as a control panel." So Microsoft is saying youshould only see this if the application is part of Windows. While it istrue that RunLegacyCPLElevated.exe is part of Windows, it isnot true that the arbitrary DLL it loads and executes is. Thisarbitrary DLL is not in a trusted location on the file system and itdoesn’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 arenot a security boundary - they don't offer direct protection. They dooffer you a chance to verify an action before it happens. Once youallow an action to proceed, there may be no easy way back."
So while Microsoft may use the word trust when in relation to UAC insome of their documentation with statements such as – "The followingillustration details the elevation prompt logic for correspondinglevels of trust." – in actual fact, even the data these UAC promptsprovide you with can’t be trusted.
Unfortunately, this particular issue I discovered also has anunintended consequence on a security policy which may be used byenterprises. There is a security policy item called "User AccountControl: Only elevate executables that are signed and validated," whichis 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, inothers about the users making a decision before it’s too late.Hopefully from this write-up, you can see that it becomes a chicken andegg situation when the user is making a decision based on a false senseof trust.
Do I think some UAC is better than no UAC? Yes. Do I think UAC thatpresents information that can not be relied upon is good for userconfidence? 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 moreseriously than just pointing at best practice guidelines that have thesame likelihood (not much) of being implemented or followed as tellingpeople not to open arbitrary executables attached to emails.
Clarification of the order in which the posts occurred:
1) Feb 4: Joanna Rustkowska's Running Vista Every Day!
2) Feb 12th: Mark Russinovich's PsExec, User Account Control and Security Boundaries
3) Feb 12th: Joanna Rustkowska's Vista Security Model ? A Big Joke?
4) Feb 13th: Joanna Rustkowska's Confiusion About The "Joke Post"