Share via

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

  • Article

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 https://msdn.microsoft.com/library/en-us/dnlong/html/AppComp.asp 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 https://msdn.microsoft.com/library/en-us/dnlong/html/AppComp.asp 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

  • Anonymous
    April 14, 2006
    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.
  • Anonymous
    April 17, 2006
    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?
  • Anonymous
    April 17, 2006
    ::SetCapture(hwnd) still works as a way to capture the mouse.
  • Anonymous
    April 19, 2006
    Joku -- .chm files (HTML help) continue to work in Windows Vista.  WinHelp applies to .hlp files.  Thanks.
  • Anonymous
    April 24, 2006
    This content will make it into the master compatibility document in the next month or so, but in the...
  • Anonymous
    May 08, 2006
    The comment has been removed
  • Anonymous
    May 17, 2006
    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?