Elevations and ILs don't define a security boundary

Feb 15, 2007 16:41 GMT  ·  By

In Windows Vista, the user Account Control is a feature that introduces an alternate privilege model by making all the users, including those in the administrators' group, run with standard user privileges. A requestedExecutionLevel key embedded in the executable of the applications must require administrative privileges. As a result, the user is presented with a UAC Consent dialog that asks for elevation of privileges.

"Whether you elevate from a standard user account (Over the Shoulder - OTS - elevation) or from an administrative account (Admin Approval Mode - AAM - elevation), you create processes that have administrative rights on the same desktop as those that have standard user rights. Processes elevated from a standard user account run in a different account from those with standard user rights, so the Windows security model defines a wall around the elevated process that prevents the non-elevated processes from writing code into those that are elevated," revealed Mark Russinovich, a Technical Fellow in Microsoft's Platform and Services Division.

In this regard, Windows Integrity mechanism comes on top of the standard Windows security model to prevent input passing from non-elevated processes to elevated processes. Windows Vista attributes an Integrity Level to every process and object. In time, Windows Vista will force all the software developers to build products for users with standard administrative privileges, unlike the current trend in XP.

"Because elevations and ILs don't define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs. So if you aren't guaranteed that your elevated processes aren't susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption," Russinovich added.