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 http://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 http://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.