USER & GDI Compat, part 4 — Cross-process and security

As an added layer of defense against malicious software, Windows Vista introduces allows different UI applications to run with three different levels of UI privilege.  Applications can freely interact with other applications of the same and lower permission, but can’t modify or talk to applications of higher permission.  Most applications will run with the middle permission, while applications that require administrator privileges run in a higher mode, and restricted processes such as low rights Internet Explorer use the lowest privilege mode. 

More specifically, applications in lower privilege modes cannot generally send messages to higher privileged applications unless the higher privileged application explicitly allows that message by calling ChangeWindowMessageFilter().  (In the February CTP, RegisterWindowMessage messages were assumed to be allowed between different privilege levels, we’re fixing that in subsequent builds)  Similarly, lower privileged applications can read but cannot modify HWNDs owned by higher privileged applications.  For compatibility reasons, SendMessage and other APIs will return success even if the API was blocked because of privilege issues.  Similarly, where compatibility impact is high and security risk is low we sometimes allow low-privileged applications to send unsolicited messages to high privileged applications.

Things to pay attention to when testing:

  • Applications that interact with other applications -- utilities that reposition windows, type keystrokes for you, add extra buttons to windows, etc.

  • Cut and paste between different applications -- does it work at all, and does it support all the different clipboard formats you expect (rich text, HTML, etc.)?

  • Help -- Does help launch?  We've made security changes to winhelp.exe and the WinHelp API, see for details.
    Internet Explorer plug-ins -- Internet Explorer runs in low rights mode, so plug-ins, ActiveX controls, and document objects that talk to other processes may not work.  We recommend testing all plug-ins, ActiveX controls, and document objects, see for details.

  • Journaling hooks – WH_JOURNALPLAYBACK and WH_JOURNALRECORD are inherently cross-process, so require the highest privilege level.

  • SendKeys in Windows Forms and Visual Basic 6.0 and earlier – As implemented today, these functions rely on journaling hooks, so don’t work if the application is not run with the highest privilege level.  We’re currently investigating options here.

Also, for programs you have the source code to, consider reviewing any code that uses the following APIs, as they often indicate cross-process stuff:

  • SendInput

  • RegisterWindowMessage

  • BroadcastSystemMessageEx

  • BroadcastSystemMessage

  • SetWindowsHook

  • SetWindowsHookEx

  • CallNextHookEx

  • CallNextHook

  • SetWinEventHook

  • AttachThreadInput

  • FindWindowEx

  • FindWindow

  • CreateDesktop

  • CreateDesktopEx

  • OpenDesktop

  • OpenInputDesktop

  • EnumDesktops

  • EnumDesktopWindows

  • SwitchDesktop

  • SetThreadDesktop

  • GetThreadDesktop

  • CloseDesktop

  • CreateWindowStation

  • OpenWindowStation

  • EnumWindowStations

  • CloseWindowStation

  • GetProcessWindowStation

That’s not an exhaustive list, nor is it a guarantee of anything that needs to change, but it’s a good balance of finding issues vs. minimizing false positives.  You can search source files with

findstr /s /g:temp.txt *.c *.cpp *.h *.hpp

where temp.txt is the above list of APIs copied to a text file.

Comments (7)

  1. Joku says:

    Do .chm files continue working or do they require optional download before they work at all? I thought I read some help stuff requiring separate download somewhere.

  2. Mike says:

    If ::SetWindowsHookEx(WH_MOUSE, …) is blocked then how can an application capture the mouse.

    Scenario: A user presses a mouse button down over the application’s window then drags the mouse outside the window area before releasing the button. How does the app get the mouse up message?

  3. nkramer says:

    ::SetCapture(hwnd) still works as a way to capture the mouse.

  4. Nick Kramer says:

    Joku — .chm files (HTML help) continue to work in Windows Vista.  WinHelp applies to .hlp files.  Thanks.

  5. This content will make it into the master compatibility document in the next month or so, but in the…

  6. David Hopwood says:

    "Similarly, where compatibility impact is high and security risk is low we sometimes allow low-privileged applications to send unsolicited messages to high privileged applications."

    When, exactly?

  7. Tomi B. says:

    Will SetWindowsHook/Ex require administrator priviledges? If so, will there be an alternate means to know when the user is active (even outside your application) without getting specific details of keypresses / mouse movements?

Skip to main content