Goa 2014:- Chrome Security 2014: New and future hotness by Sumit Gwalani

### Overview In this presentation at Nullcon Goa 2014, Sumit Gwalani of the Chrome security team details recent architectural defenses and future security initiatives across the Chrome browser and Chrome OS. Guided by the core engineering principles of speed, simplicity, and defense-in-depth security, Gwalani highlights how the team mitigates entire vulnerability classes rather than relying on one-off fixes. The talk spans user-space mitigations, kernel-level sandboxing, cryptographic hardware roots of trust, and community vulnerability reward initiatives.

### Key Topics - **Core Design Principles**: Building transparent, performant security that does not impede UX, treating security as an engineering-wide responsibility, maintaining rapid patch turnaround times (<24 hours), and keeping security designs public. - **Chrome Browser Mitigations**: Mitigating use-after-free and type confusion vulnerabilities via PartitionAlloc and V8 JavaScript-to-C++ binding integrity checks, cert pinning to Google intermediate CAs, and blocking NPAPI plugins by default. - **Continuous Testing via ClusterFuzz**: Running automated large-scale fuzzing across hundreds of VMs and thousands of Chrome instances with AddressSanitizer (ASan) to catch memory safety bugs pre-release. - **Site Isolation**: Developing a site-per-process model to allocate separate sandbox processes to distinct web origins, mitigating cross-site iframe leaks and renderer-initiated navigations beyond basic Same-Origin Policy. - **Chrome OS Hardware Root of Trust**: Implementing Verified Boot via static read-only firmware, cryptographic signature chains (RSA 8192-bit down to 2048-bit), and kernel `dm-verity` hash trees for block-level execution verification while maintaining sub-10-second boot times. - **Data Protection & System Hardening**: Employing TPM-backed encryption for user home directories (eCryptfs) and system storage (dm-crypt), sandboxing system daemons using the `minijail` helper, implementing `seccomp-bpf` filters across renderers and GPU processes, and contributing Kernel ASLR (KASLR) upstream to Linux. - **Vulnerability Rewards Program (VRP)**: Incentivizing researchers through Chromium VRP, Pwnium competitions, and programs paying for open-source patches in core third-party open-source libraries and the Linux kernel.

### Technical Details - **PartitionAlloc**: Partitions heap allocations by object hierarchy (e.g., dedicated heaps for DOM nodes, Blink/WebKit rendering nodes, and user-controlled buffers like array buffers and strings) isolated with guard pages to prevent cross-object type confusion during use-after-free conditions. - **Binding Integrity**: Stores unguessable representations of V8 object types inside C++ objects using ASLR defenses; validates wrapper types upon object creation without requiring costly per-call validation overhead. - **ClusterFuzz**: Automates crash detection, minimizer workflows, and test execution using AddressSanitizer (ASan) builds with poisoned `malloc` and `free` routines, catching over 1,000 vulnerabilities prior to release. - **Verified Boot & dm-verity**: Boot execution verifies a chain from read-only firmware (8192-bit RSA) to read-write firmware (4096-bit RSA) to the kernel partition (2048-bit RSA). The kernel validates root filesystem blocks on access using a hash tree rooted in a parent hash passed via the kernel command line (`dm-verity`). - **Storage Encryption**: User home directories are encrypted with 128-bit AES keys wrapped by 512-bit and 2048-bit RSA keys derived jointly from user credentials and the hardware TPM chip, simultaneously providing anti-theft protection and hardware-enforced brute-force rate-limiting. - **Seccomp-BPF & KASLR**: Employs Berkeley Packet Filter program decision trees to inspect system call numbers and arguments without loops. Used in renderer processes (alongside setuid sandboxing) and GPU processes (via an intercepting helper process). Added x86 Kernel ASLR support by walking e820 memory regions and randomizing boot locations using CPU primitives like `RDRAND`, coupled with restrictions on `dmesg` and kernel pointer leaks.

### Takeaways Chrome and Chrome OS treat security as an end-to-end systems challenge spanning hardware, kernel primitives, and user-space memory allocators. By introducing structural architectural barriers (like PartitionAlloc, Site Isolation, dm-verity, and seccomp-bpf), attackers must chain together significantly more zero-day vulnerabilities (moving from single-bug exploits to chains of 6 to 14 bugs). The team also actively upstreamed core defenses (such as `dm-verity` and Linux KASLR) and continues to fund external hardening through proactive bug bounties and open-source patch rewards.