Presentation Material
Abstract
In recent years, the focus of black hats has moved from finding vulnerabilities in the operating system to application software. This shift in their focus has been facilitated by the emergence of publicly available fuzzing frameworks that help easy discovery of vulnerabilities in desktop applications. These vulnerabilities enable attackers to steal data from the victims and to install back doors through which the attackers can return for further exploitation. They thus pose a huge risk. Majority of these attacks target ubiquitous and ppularly used applications like Adobe Reader, Flash Player and Microsoft Office Suite. In an era where IT drives business, security breaches in software can cause huge credibility losses for the software vendors. In response to this problem, vendors are trying to improve the security of their applications by implementing newer security measures. Sandbox is one such technology which protects the system from being compromised even if the attacker succeeds in finding a vulnerability in the application code. This is achieved by limiting the capabilities of the sandbox process so that it cannot install malware or steal data from the user’s machine. The sandbox thus provides defence-in-depth protection against un-patched or unknown vulnerabilities in the core application.
This paper intends to explain “sandboxing” as a technique for threat mitigation. It gives technical details of how to implement sandboxing while developing windows applications, taking Adobe Reader (version X) as a case study. The paper also explains the mitigations provided by the sandlX’x design and the typical challenges that come about while implementing such a technology in one’s application.
- video removed https://www.youtube.com/watch?v=VDaFAR3Tnoo&list=TLocA9-k_q006KXa0lysAcPaPYdpEc4Y78
AI Generated Summary
This talk addresses the implementation of application sandboxing as a defense against exploit-based attacks, using Adobe Reader as a case study. It argues that while operating system-level exploit mitigations (e.g., ASLR, DEP) are valuable, they are often insufficient for complex legacy applications due to compatibility constraints and third-party library dependencies. The presented solution confines the application’s processing of untrusted data (e.g., PDFs) within a highly restricted sandbox process.
The core technical implementation relies on a two-process architecture on Windows. A low-privilege “sandbox” process handles untrusted content, while a full-privilege “broker” process mediates all requests for system resources like file or registry access. The sandbox is enforced through several Windows mechanisms: a restricted user access token (with denied privileges and SIDs), job object limits (e.g., constraining process creation), and a low integrity level (preventing cross-process message attacks). The broker enforces a security policy, only permitting operations deemed safe for the application’s workflows.
Key challenges in deploying such a sandbox include ensuring compatibility with plugins and accessibility tools, which often require elevated privileges, and resolving conflicts with antivirus software that also employs hooking techniques. The broker process itself is a critical attack surface; its codebase must be minimal, rigorously reviewed, and penetration-tested. The primary mitigation provided is that even if exploit code executes within the sandbox, its inability to launch external processes, modify the registry, or access sensitive system objects prevents meaningful system compromise. The approach represents a shift from solely preventing exploit execution to containing the impact of a successful exploit.