I was reading Raymond’s post on Escalation of Privilege bugs that don’t actually escalate your privilege and then quickly read the earlier episode of the series. There I saw a lot of commenter rebilling against the concept of post by drawing new security boundaries which the hypothetical exploit would cross. This crystallized a concept for me that there are certain security boundaries in windows that are harder then others and there is much confusion in this area. Since I haven’t seen this information in one place anywhere, I’ll try to consolidate my understanding of it here.
Security Boundaries control the flow of information and execution between two distinct environments. We consider a boundary breached when arbitrary data or execution is no longer prevented from occurring. Most of the time we consider one of the environments a superset of the other, for example, going from executing as a single user to controlling the entire Operating System. However any attack that gives you more privileges then you currently have can be considered an escalation of privilege.
- Primary Security Boundaries
- The Remote Boundary (is there a better name?)
The User Principle Boundary
- This boundary separates things executing off your computer and on your computer. When an attacker can remotely make your computer do arbitrary things in a security context that would be crossing the remote/machine boundary.
The Administrator/Kernel vrs Not Boundary
- This refers to the security boundary created by executing code under a security principal and the ACLs that details which user has access to which resources. This is what keeps one user from snooping on another user’s files. If untrusted code manages to run in your user account, it’s not really your user account any more. This can also refer to non user accounts such as services.
- This is the boundary between a normal user and running as administrator or executing code in the kernel. Once untrusted code is running in either administrator or in the kernel, it is not your box anymore.
The Operating System Boundary
- These carve out boundaries like ACLs.
Managed Code (CLR/Java) sandboxing
Mitigation Boundaries (These are bypass-able, have uses and may be put together to make something stronger but alone do not form a primary security boundary, see Mark’s blog)
- This boundary refers to the ability to read files and execute when it is allowed to execute outside the context of the operating system normally in control of the resources. If the OS isn’t running it can’t protect secrets. Technologies like bitlocker and the one-way encryption of passwords are attempt to deal with breaches of this boundary. Vitalization is making this area more interesting.This is also the point of Immutable Law #3.
- Power User/Administrator/Kernel/System
Vista Admin account UAC
- You can switch between these without much difficulty.
- The split token helps but doesn’t make a full boundary
Software Restriction Policies
UAC elevated processes in a user session
Kernel Driver Signing
Kiosk style, certain applications only hacks/setting changes
System File Protection
Windows Data Protection – DPAPI
- Different user sessions have different named object namespaces ACL’d to them, however one user could reach over and mess with then session of another instance of the same user.
Much of the confusion occurs from “breaching” a Mitigation Boundary instead of one of the Primary Security Boundaries. Aside from some nice new Mitigation Boundaries, the main thing that Vista does is move most users from the Administrator/Kernel side to the rest side or the primary boundaries #3, and that is a big deal.