Response from Arjun Baokar =========================== 1) What kind of attacks does the NaCl sandbox aims to prevent? NaCl aims to prevent arbitrary code execution attacks that may result from untrusted binaries. These include binary validation, OS system-call interception, trampoline attacks, and exploits that write to the trusted stack. 2) Summarize the architecture of the NaCl sandbox and explain how it prevents the attacks above NaCl has an inner and outer sandbox, isolated exceptions, and service runtime facilities. The inner sandbox enforces rules on the untrusted code and uses a static analyzer to confirm those rules. It enforces data integrity, reliable disassembly, no unsafe instructions, and control flow integrity (CFI). It does this by combining CISC fault isolation and 80386 segmented memory to create a data sandbox. It ensures reliable disassembly by making binaries non-writable in memory and by making all valid instructions are reachable from the base address. It blacklists instructions it considers unsafe, and maintains CFI by implementing its own nacljmp instruction and ensures that any address reachable from the set of instructions reachable from the start address is also in the set. The outer sandbox mediates system calls; it provides defense in depth. Each NaCl module runs in its own OS process to isolate exceptions to try and prevent exploits that involve exceptions. However, it does not stop SEH exploits. The service runtime helps prevent trampoline attacks by blocking system-call trampolines with a hlt instruction. It prevents attacks from abusing its springboard by requiring alignment. Per-thread trusted stack lives outside the untrusted address space to stop threading attacks from reaching it. The IMC provides a communication channel and allows the creation of shared memory between NaCl modules.