Diving Into IE 10’s Enhanced Protected Mode Sandbox by Mark Vincent Yason

### Overview Mark Vincent Yason from IBM X-Force presents an in-depth analysis of Internet Explorer 10's Enhanced Protected Mode (EPM) sandbox on Windows 8 and 8.1 (also applicable to IE 11). EPM builds upon IE7's Protected Mode: while Protected Mode focused on limiting write access to prevent persistent malware, EPM adds read access restrictions and limits sandbox process capabilities using Windows 8 AppContainers. EPM is enabled by default in immersive IE but disabled by default in desktop IE. The presentation covers the internal architecture of EPM, remaining limitations and weaknesses, potential escape vectors, and a live demonstration of a sandbox escape via a command-line parsing flaw.

### Key Topics - **Architecture and Internals**: The browser architecture separates duties between a medium-integrity broker process (frame process) and a low-integrity sandbox tab process running in an AppContainer. Isolation relies on lowbox tokens containing AppContainer SIDs, lowbox IDs, and capabilities (e.g., Internet Client and IE capabilities). Communication relies on `IEHost`/`IEShims` compatibility layers, elevation policies, COM IPC (bootstrapped by marshalling user broker objects), and Shared Memory IPC (divided into spaces, containers, and entries/artifacts). - **Sandboxing Mechanisms & Access Controls**: Securable objects require specific Access Control Entries (ACEs)—either specifically for the AppContainer, for `ALL APPLICATION PACKAGES`, or matching capability ACEs. Browser-specific locations (favorites, feeds) use an IE capability ACE, while app-specific storage exists in dedicated folders and registry keys. Object directory namespacing, global atom tracking, and UIPI prevent cross-container tampering. - **Missing Restrictions and Weaknesses**: EPM omits several standard hardening techniques: job object limits, restricted tokens, and desktop/window station isolation are not implemented. As a result, sandboxed code can access system files and keys with `ALL APPLICATION PACKAGES` read ACEs, access EPM cache and cookies, read/write clipboard data when receiving keyboard focus, and perform screen scraping via unblocked read-type window messages (`WM_GETTEXT`) or screen capture. - **Sandbox Escape Vectors**: Escape techniques include kernel bugs (e.g., win32k vulnerabilities), permissive elevation policies/permissions, vulnerable broker services reachable via IPC, and policy check vulnerabilities.

### Technical Details - **Elevation Policies**: Stored in the registry, these define launch behaviors for intercepted APIs: Policy 0 blocks execution (e.g., `cmd.exe`), Policy 2 prompts the user, and Policy 3 allows launching in medium integrity without prompt (e.g., `notepad.exe`). - **The Parsing Flaw**: Yason discovered a flaw in how command lines are evaluated prior to elevation checks. When delimiting the application name and command-line arguments using a tab character (`\t`) instead of a space, the broker's parser evaluated the binary as `notepad.exe` (matching Policy 3), but passed the unparsed command line to `WinExec`, causing Windows to execute `cmd.exe` directly in medium integrity. - **Exploitation**: The presenter demonstrated code injected into the sandbox process (both in desktop EPM and immersive IE) issuing the tab-delimited command string to the broker, resulting in `cmd.exe` and `calc.exe` spawning at medium integrity without user prompts.

### Takeaways AppContainers significantly reduce the attack surface by restricting access to personal files and corporate intranet resources. However, broad read permissions granted to `ALL APPLICATION PACKAGES` for compatibility, lack of desktop/job isolation, and parsing inconsistencies in privileged broker services leave viable paths for information disclosure and sandbox escape. Securing sandboxes requires rigorous validation of input parsing logic and layering additional isolation primitives such as restricted tokens and desktop isolation.