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.
> *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
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]