Two Vista bugs on security blogg

These two entries came from a security forum hosted by Semantec, an anti-virus vendor. The research conducted by Orlando Padilla of Semantec on the Windows Vista operating system initially showed it was quite resilient to normal virus or trojan configuration or payload.

    It is possible however that
an entirely new breed of malware may be spawned to take advantage of cracks in the Vista OS. Certain programming and design flaws in the OS are still apparents as shown by this posts.  (yul3452)

1. System message vulnerability

    A vulnerability has been discovered in the way the Windows Client/Server Runtime Server Subsystem (CSRSS) processes a type of system message referred to as the HardError message, reportedly allowing a logged on user to execute arbitrary code in the CSRSS.EXE process and elevate their privileges to SYSTEM level. The vulnerable code is present in the new Vista operating system, as well as Windows 2000, XP and 2003.

    When certain events occur within the operating system, a HardError message is sent to CSRSS containing the caption and text of a message box to be displayed in order to notify the user of a critical system error.

    The HardError message is handled by a function in WINSRV.DLL which returns pointers to the caption and text of the message box.

    If the caption or text parameters are prefixed with certain characters, the function erroneously frees the buffer holding the text and returns a pointer to freed memory. After the message box is closed by the user, the same buffer is then freed again, resulting in what is known as a double-free vulnerability.

    Microsoft has been notified and is working on a patch.

2. 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."

    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.

    A Microsoft’s Technet document "Understanding and Configuring User Account Control in Windows Vista" shows a flowchart with 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 issue I discovered was that the binary RunLegacyCPLElevated.exe could be abused. The code is signed by Microsoft and ships with Windows Vista by default with a manifest that says it needs to run on an elevated privilege and is considered part of the core operating system.

    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(
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 teal colored dialog box with "Blue/green background: the application is a Windows Vista administrative prompt similar to 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 on a trusted location on the file system and it doesn’t even have 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 Olie Whitehouse