1. Secure web browsers, malicious hardware, and hardware support for binary translation Sam King

2. Browser motivation Browsers most commonly used application today Browsers are an application platform – Email, banking, investing, shopping, television, and more! Browsers are plagued with vulnerabilities – Internet Explorer: 57 vulnerabilities – Mozilla/Firefox: 122 vulnerabilities – Safari + Opera: 66 vulnerabilities Studies from Microsoft, Google, and University of Washington show web browser is attacker target 2/14

3. The OP Browser Goal: build a secure web browser Provide an architecture for secure web browsing – Maintain security guarantees even when compromised Driven by OS and formal methods design principles 3/14

4. OP design Decompose into browser subsystems – Web page instance further divided Use message passing – All messages through browser kernel Dedicated subsystems for OS operations Host OS sandboxing 4/14

5. Design enables security Partitioning and constrained communication enable new security mechanisms – Clean separation of browser functionality and security Policy – Plugin security policies, xss Formal methods – SOP + URL address bar invariant 5/14

6. Research questions OP: more secure browser can be practical – Hopefully no longer weakest link in comp. stack Can you operate with a malicious OS? – What portions of the OS does browser kernel replicate? – What portions of the OS does browser kernel rely on? 6/14

7. Replicate portions of the OS Extracts parts of OS needed for web client sec – Custom labeling and access control system – RPC / message passing layer – Window manager (limited extent) 7/14

8. Assumptions about OS Process-level isolation (easy) – Memory protection – well-known IPC mechanisms System-level sandboxing (moderate) – Isolate processes from system resources – Restrict system call capabilities Resource management (hard) – Create processes, message forwarding and naming – Network, disk, screen Possible techniques for enforcing assumptions – Bottom up: SVA, binary trans, hardware isolation primitives – Top down: Simple web client, not a full browser 8/14

9. Untrusted computing base: defending against malicious hardware

10. Building secure systems We make assumptions when designing secure systems Break secure system, break assumptions – E.g., look for crypto keys in memory People assume hardware is correct What if we break this assumption? 10/14

11. Malicious hardware Is it possible to modify design of processors? Implementing hardware is difficult Implementing HW-based attacks is easy! – Small hardware level footholds – Execute high-level high-value attacks WITHOUT exploiting any software bugs 11/14

12. Defenses Based on insights from foothold devel. Analyze circuit at design time Highlight potentially malicious circuits Closely related to operating systems – Both have symbolic representation, compiled – 3 rd party tools and libraries – Principles learned from exercise could apply to OS Fundamentally an issue untrusted lower layers 12/14

13. Hardware support for dynamic binary translation

14. H/W for dynamic bin. trans. Problem: instrument individual inst is slow – Especially true for security applications Goal: amortize the cost across mult. instructions – Fast path for common case, efficient check for correct E.g., don’t read tainted memory – Slow path for correct (fully instrumented) case Solution: hardware support – HW signatures (e.g., bloom filter) to summarize E.g., addresses for load / store instructions – Apply known tricks to security case Extra registers, parallel optimization, atomic regions, etc. 14/14

15. Questions? 15/14

16. Performance Load latencies do not impact usability Load time in seconds 16/14