Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
*This session talks about the technology behind this change to Windows, including the isolation of Admin from Standard User code on the same desktop,
I would like to add that running higher priveleged applications on the same desktop as lower priveledged ones is accompanied by a security-relevant design flaw in Windows' unauthenticated window message system allowing shatter attacks on windows of higher-priveledged processes. I'd reference to the excellent work of Chris Paget for further details. Windows Vista was aimed to bring UIPI, adding a "privelege level" to the process structure and changing the messaging system in a way so that windows with "lower" priveleges are not allowed to send messages to windows with "higher" priveleges, however, as far as I can see, one can only make use of this feature for processes started with a filtered token or software explicitly using SetNamedSecurityInfoW calls, so threats may remain for services with GUI components and high-priveleged applications started via runas or EPAL. | All applications run by a limited user have the same UI privilege | level. As a limited user, applications are run at a single privilege | level. UIPI does not interfere or change the behavior of window | messaging between applications at the same privilege level. UIPI | comes into effect for a user who is a member of the administrators | group and may be running applications with least privilege (sometimes | referred to as a process with a filtered token) and also processes | running with full administrative privileges on the same desktop. UIPI | prevents lower privilege processes from accessing higher privilege | processes by blocking the following behavior. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp Denis --------------------------------------------------------------------------- ---------------------------------------------------------------------------
