570 likes | 705 Views
Windows Vista Security: User Account Control and Protected Mode IE. EUSEC West February 2, 2007. Mark Russinovich Technical Fellow PSD Microsoft Corporation. About Me. Technical Fellow, Microsoft Co-founder and chief software architect of Winternals Software
E N D
Windows Vista Security:User Account Control and Protected Mode IE EUSEC West February 2, 2007 Mark Russinovich Technical Fellow PSD Microsoft Corporation
About Me Technical Fellow, Microsoft Co-founder and chief software architect of Winternals Software Co-author of Windows Internals, 4th edition and Inside Windows 2000, 3rd Edition with David Solomon Author of tools on www.sysinternals.com Home of blog and forums Contributing Editor, Windows IT Pro Magazine, TechNet Magazine Ph.D. in Computer Engineering
Outline User Account Control Goals Running as Standard User Conveniently Accessing Administrative Rights Isolating Elevated Processes Protected Mode Internet Explorer UAC’s Impact on Malware
UAC Goals Enable users run to run with standard user rights Prevents deliberate (and accidental) modification of system settings Reduces malware impact by preventing modification of security settings and hardware Prevents compromise of sensitive information on shared computers
UAC Goals (cont) To get there Windows had to address several problems: The Windows usage model has been one of administrative rights Applications use them without knowing it Those that need it don’t distinguish administrative from standard user actions Users want administrative rights to easily perform operations that require them Software installations Changing the time zone Changing firewall settings Etc.
The UAC Solution Make it possible to run most applications with standard user rights Change the rights requirements of Windows operations Enable legacy applications to run with standard user rights Remove reasons for users to run as administrators at all times Make it convenient to access administrative rights when necessary Encourage ISVs to code new applications to run with standard user rights Enable even administrators run as standard users
Outline User Account Control Goals Running as Standard User Conveniently Accessing Administrative Rights Isolating Elevated Processes Protected Mode Internet Explorer UAC’s Impact on Malware
Making Windows Standard User-Friendly In Vista, many previously-admin operations are accessible by standard users: View system clock and calendar Change time zone Configure Wired Equivalent Privacy (WEP) to connect to secure wireless networks Change power management settings Add printers and other devices that have the required drivers installed on computer or have been allowed by an IT administrator in Group Policy Install ActiveX Controls from sites approved by an administrator Create and configure a Virtual Private Network connection Install critical Windows Updates
Helping Legacy Applications Run as Standard User Many applications would run fine as standard user, but they needlessly store data in HKLM\Software or %ProgramFiles% They use these locations for per-user data, not global data These locations are system-global and so only writeable by administrators It’s always worked because Windows users have always been administrators The solution: help them through virtualization Modifications of most system-global locations go to per-user areas Reads generally go to the per-user location and fall back to the global location
Virtualized Processes Processes are virtualized unless: They are 64-bit They have a requestedExecutionLevel in their executable manifest Most Windows Vista executables They are running with administrative rights (described later) Note: operations not originating from an interactive login session are not virtualized e.g. file sharing Can be turned off globally via local security policy setting (secpol.msc):
Virtualized Files Redirected file system locations: %ProgramFiles% (\Program Files) %AllUsersProfile% (\ProgramData – what was \Documents and Settings\All Users) %SystemRoot% (\Windows) %SystemRoot%\System32 (\Windows\System32) Exceptions: Files that have executable extensions (.exe, .bat, .vbs, .scr, etc) Prevents masking of executables for servicing and security Exceptions can be added in HKLM\System\CurrentControlSet\Services\Luafv\Parameters \ExcludedExtensionsAdd Per-user virtual root: %UserProfile%\AppData\Local\VirtualStore Note: Virtual files do not roam with Roaming Profiles
Viewing Virtualized Files Explorer shows a Compatibility Files button when there are virtual files present Opens view of virtual location
File Virtualization Implementation File system virtualization is implemented in a file system filter driver, luafv.sys Legacy Application Vista Application \Windows\App.ini User Mode Kernel Mode Luafv.sys \Users\<user>\AppData\Local\VirtualStore\Windows\App.ini \Windows\App.ini Ntfs.sys Access Denied
Registry Virtualization Redirected locations: HKLM\Software Exceptions: HKLM\Software\Microsoft\Windows HMLM\Software\Microsoft\Windows NT Other subkeys under Microsoft Per-user virtual root: HKEY_CURRENT_USER\Software\Classes\VirtualStore
Registry Virtualization Flags Each Registry key under HKLM\Software has three new flags: Don’t Virtualize: disable virtualization Don’t Silent Fail: if not virtualized, return maximum-allowed access instead of error Recurse: propagate flags to child keys Windows Vista Reg.exe is flag-aware:
Registry Virtualization Implementation Registry virtualization is built-into the Registry Legacy Application Vista Application HKLM\Software\App User Mode Access Denied Kernel Mode Ntoskrnl.exe HKCU\Software\Classes\VirtualStore\Machine\Software\App Registry
Application-Specific Behavior Some applications have to be helped in other ways to run as Standard User Windows Vista includes built-in application-compatibility shims Users can define shims for other applications Most common standard user shims: ForceAdminAccess: spoofs queries of administrator group membership VirtualizeDeleteFile: spoofs deletion of global file LocalMappedObject: forces global section objects into user’s namespace VirtualizeHKCRLite, VirtualizeRegisterTypeLib: redirects global registration of COM objects
User-Applied Shims If an application runs as administrator, but fails as standard user, use the Standard User Analyzer (SUA) to watch its behavior Free download from Microsoft Doesn’t necessarily see all administrator operations Assign the application shims with the Compatibility Administrator Part of the Application Compatibility Toolkit from Microsoft Creates a Shim Database (.sdb) that you can install manually or with Sdbinst.exe
Outline User Account Control Goals Running as Standard User Conveniently Accessing Administrative Rights Isolating Elevated Processes Protected Mode Internet Explorer UAC’s Impact on Malware
Accessing Administrative Rights Problem: there are still operations that require administrative rights: Installing applications Modifying system-global settings Parental controls Solution: make it convenient to access administrative rights from standard user accounts Identify operations that require administrative rights Allow for “run as” functionality Called Over The Shoulder (OTS) elevation when accessed by a standard user account Called Consent elevation when accessed by Admin Approval Mode
Administrator Approval Mode Problem: even administrators should run as standard user Otherwise, there would be no major shift out of the Windows administrator environment But have to make it convenient to access administrator rights Solution: have administrators run with a split personality Two identities created for user when they login: User as standard user User as administrator Called Admin Approval Mode (AAM)
Recognizing Administrators User is considered an administrator if they belong to any admin-type group e.g.: Administrators Controllers Certificate Administrators Enterprise Administrators Schema Administrators
Recognizing Administrators (cont) User is considered an administrator if they have any administrator privileges: Create Token TCB Take Ownership Backup Restore Debug Impersonate Relabel Load Driver
Administrator’s Standard User Identity: Groups Administrator’s standard user token is subset of their full administrator token Administrator groups are marked as “deny only” groups Applies to Domain Administrators, Builtin\Administrators and others Can only be used to deny access, never to grant E.g. if file only allows administrator access, user is denied access E.g. if allows a user’s group access, but denies administrators, user is denied access
Administrator’s Standard User Identity: Privileges • All privileges except the following are stripped: • Change Notify • Shutdown • Undock • Reserve Processor • Time Zone • When authenticating to remote resources: • If system is non-domain joined, user authenticates as standard user • If domain-joined and an administrator of the remote resource, user authenticates as administrator
Requesting Administrator Rights There are four mechanisms whereby administrator rights can be requested: Executable manifest file includes a elevation level that asks for it Process launch believes executable is a setup program E.g. name has “setup”, “update” or “install” or it has bytes of known setup engines User asks for it by selecting “Run as administrator” option from Explorer context menu or shortcut property Application Compatibility database includes an ElevateCreateProcess shim for the executable Windows and applications identify administrator operations with a shield icon
Requesting Administrator in a Manifest Manifest files were introduced in Windows XP to support side-by-side DLLs Used for XP’s Common Control v6 dialog .NET uses it for managed code “assemblies” Embedded in resources of binary file Vista introduces a new key, requestedElevationLevel, that can be one of three values: asInvoker: Run with the user’s rights highestAvailable: if standard user then don’t ask, but if user is an administrator, then ask requireAdministrator: always ask
Elevation Prompts Dialog gives user information on what is asking for administrative rights File description, if executable is digitally signed; otherwise file name Publisher, if executable is digitally signed Opening Details reveals command line Coloration indicates level of trust for the application source Blue: core Windows components in protected locations Grey: all other digitally signed code Orange: unsigned code - do not run unless you know the source OTS: Dialog contains “tiles” for known administrator accounts Credentials create new logon session token AAM: Dialog has “Continue” and “Cancel” button Continue unlocks Administrative token
Elevation Prompt Internals Elevation dialog is presented by Consent.exe Displays on secure desktop to prevent UI interference Child of Service Host (Svchost.exe) process containing AppInfo service Elevated processes are created by AppInfo service It’s re-parented to look like a child of the requesting process via a new CreateProcess parameter
Elevation Prompt Internals (cont) ShellExecute( Admin.exe) CreateProcessAsUser( Admin.exe) AppInfo Service Admin.exe RPC Explorer Consent.exe Re-parented Local System Administrator Standard User
Prompting Caveats Consent and OTS dialogs only identify the primary executable They do not identify other code, such as DLLs the executable may load or processes the executable may start Display on a secure desktop does not prevent credential dialog spoofing Allows user to “own” the administrator account and its data (not the system, though) Home users should configure Control+Alt+Del Group policy setting
Configuring OTS CAD • Access the setting with the Group Policy Editor (gpedit.msc) • Note that AAM elevation will not go to the secure desktop when this is enabled (will be fixed in SP1)
Disabling OTS OTS is discouraged for corporate environments It’s availability will cause help desk calls Can be turned off through security policy
Outline User Account Control Goals Running as Standard User Conveniently Accessing Administrative Rights Isolating Elevated Processes Protected Mode Internet Explorer UAC’s Impact on Malware
Isolating Elevated Processes Problem: elevated processes run on the same desktop as standard user processes Solution: Windows Vista isolates the windows and processes of elevated processes Window isolation is called User Interface Privilege Isolation (UIPI) Prevents malware from “driving” the input of an elevated process Does not prevent accessibility apps (e.g. on-screen keyboard) from sending input Prevents malware from executing “shatter attacks” In AAM, additional process isolation is required because otherwise a user has full access to their own process, including elevated processes
Windows Integrity Level Mechanism Underlying technology is a new Integrity level mechanism Integrity levels are assigned to processes (subjects) and objects Integrity policy restricts access granted by Discretionary Access Control (DAC) security model
IntegrityLevels and policy Integrity levels defined by Security IDs (SIDs) The RID defines the integrity level Primary integrity levels Low S-1-16-4096 (0x1000) Medium S-1-16-8192 (0x2000) High S-1-16-12288 (0x3000) System S-1-16-16384 (0x4000) Integrity level policies associated with generic access rights No-Write-Up - lower IL process cannot modify higher IL object No-Read-Up – prevents lower IL process from having generic read No-Execute-Up – prevents lower IL process generic execute access Default policy is No-Write-Up Plus No-Read-Up for processes
Process Integrity Level Security token in every process is assigned an integrity level Examples of assigned levels: Low Protected-mode IE, and processes started by PM IE Medium Standard user processes, non-elevated admin Accessibility processes run at slightly above Medium High Elevated Administrator processes System Local System, Local and Network Service processes Process usually inherits the IL of its parent If an executable file has an explicit IL, process will have an IL that is the minimum of parent’s and file’s Processes can also be created at an explicit IL (e.g. elevation) Ways to view a process’ integrity level: Command: Whoami /all Sysinternals Process Explorer and AccessChk
Object Integrity Levels Every securable object has an IL, either explicit or implicit Processes, threads and tokens always have an explicit IL Objects have an implicit level of Medium Most objects are Medium IL Objects created by medium+ processes get medium IL Objects created by low IL processes get low IL Built-in Icacls utility and Sysinternals AccessChk show object integrity levels
Integrity Level in Security Descriptors Object integrity level is defined by a new Mandatory Label Access Control Entry (ACE) type SID in the label ACE identifies the integrity level Label ACE is stored in the System Access Control List (SACL) SACLs also store audit ACEs Reading audit ACEs requires the Security privilege, but reading a label ACE requires only Read Permissions access (READ_CONTROL) Access Deny Access Allow Object MarkRuss Devs MarkRuss Read Full DACL SACL Audit Fail Integrity Level MarkRuss Medium Security Descriptor Read No Write Up Label ACE
Modifying Object Integrity Levels A process can modify an object’s integrity level if: It has WRITE_OWNER permission and has an IL equal to or higher than the IL of the object Note that WRITE_OWNER allows only lowering of the integrity level Or it has the new “Modify an Object Label” privilege (SeRelabelPrivilege) Not assigned to any account by default
Integrity Levels and Access Checks Integrity check implemented in AccessCheck() API Integrity check happens before discretionary access check A thread can only open an object for write access if its token IL is equal to or higher than that of the object For example, a Low IL process cannot open a Medium object for Write access, even if the DACL grants the user Write access Threads can open any object for read access Exception is process/thread because “no read up” flag is set in their label ACE Thread IL must be equal to or higher than process IL to open it Prevents sensitive information (e.g. passwords) leakage via memory reads
Object Versus Process Accesses Objects Processes High High Medium Medium Medium IL Process Low Low Low IL Process Read Write
Integrity Levels and User Interface The Windows subsystem also honors integrity levels with UIPI Lower IL process cannot send window messages to a window of a higher IL app based on filter Certain read-type messages are allowed past filter and can be sent to the higher IL windows process Higher IL process can register additional messages that pass filter (ChangeWindowMessageFilter) Lower IL process cannot install hooks Prevents “shatter” attacks
Elevation Caveats Elevations are not a security boundary There is no guarantee that malware can’t hijack the elevation process or compromise an elevated application Potential elevation techniques include: Side-by-Side code injection or replacement of private DLLs Squatting on or compromising Base Named Objects (e.g. shared memory, synchronization objects, etc.) Running something other than what you specified In AAM, elevated processes share state with standard user environment e.g. HCKU, environment variables In AAM, malware can drive input Switch to a dedicated administrator account for securely running as administrator
Disabling UAC UAC can be turned off through security policy (and UI): Note: this also turns off Protected-Mode IE
Outline User Account Control Goals Running as Standard User Conveniently Accessing Administrative Rights Isolating Elevated Processes Protected Mode Internet Explorer UAC’s Impact on Malware
Protected-Mode Internet Explorer • Problem: “drive-by-download” malware uses buffer overflows and other vulnerabilities in IE, IE extensions, and ActiveX controls to compromise the user • Modifies behavior of user’s account • Installs malware • Solution: IE 7 on Vista uses integrity and UIPI to isolate IE from the user’s other processes, windows and settings • Runs IE at Low IL • Also called Low-Rights IE (LoRIE) • Objects that must be writeable by IE are set to Low IL e.g.: • Temporary Internet Files • Cookies • Recycle Bin • Various Registry keys, including ones under HKCU\Software\Microsoft\Internet Explorer
Saving Content in Protected-Mode IE • IE promotes explicitly downloaded content to Medium • Makes it equivalent to the user’s other data and code • Prevents malware from tampering with it • IE running at low can’t do that itself • Downloads first to a Low directory • Asks IEUser.exe, which runs at Medium IL, to promote: IEUser.exe (Medium) IEShowFileSaveDialog IESaveFile IExplore.exe (Low)