Presentation Material
Abstract
As we secure applications leveraging sandboxes, it is important to understand the attack surface as it presents opportunities for attackers. In this talk we’ll decompose application sandboxes from the lens of a pen-tester. We look at various popular sandboxes such as Google Chrome, Adobe ReaderX, and Sandboxie, amongst others, and discuss the limitations of each technology and its implementation details. Further, we discuss in depth with live exploits how to break out of each category of sandbox by leveraging various kernel and user mode exploits – something that future malware could leverage. Some of these exploit vectors have not been discussed widely and awareness is important.
AI Generated Summary
The talk examines the architectural security of application sandboxing on Windows, categorizing common implementations into two types. Type A sandboxes (e.g., Sandboxie) use a kernel driver to virtualize file and registry access within a container, enforcing policies at the kernel interface. Type B sandboxes (e.g., Chrome, Adobe Reader) employ a master-slave model where a privileged master process mediates all access requests from a confined slave process via inter-process communication (IPC), with the slave running at a low integrity level.
The core argument is that both architectures are fundamentally vulnerable because the sandboxed process retains direct access to the Windows kernel and certain user-mode system services. A kernel vulnerability (e.g., in win32k.sys) allows a sandboxed process to gain system privileges, completely bypassing sandbox policy enforcement, as demonstrated with a real-world exploit. Even without a kernel flaw, Type A and Adobe Reader’s Type B implementation expose numerous ALPC ports to the sandbox. A vulnerability in a system service like csrss—specifically, a permission validation flaw enabling shatter-style attacks—can be exploited from within the sandbox to execute code in a higher-privilege context, as shown via a csrss exploit that performed keystroke injection and data exfiltration.
Chrome’s Type B implementation is noted as more robust due to extensive hardening of the master process and restrictive policies that limit kernel and service exposure, making escapes more complex. However, its slave process still interfaces with the kernel, leaving it susceptible to kernel exploits.
A new threat category, “sandbox leakage,” is introduced where malware inside a sandbox can still perform surveillance (keylogging, webcam/mic activation) on the host without escaping, due to direct access to user-mode hardware interfaces.
The practical implication is that application sandboxes on Windows provide a defense-in-depth layer but are not a boundary against a compromised operating system. Their security is limited by the kernel’s large, frequently vulnerable attack surface and the exposure of unhardened user-mode services. Effective mitigation requires reducing the kernel attack surface and rigorously restricting all IPC and service access from sandboxed processes, beyond simple integrity levels.