Secure web browsers, malicious hardware, and hardware support for binary translation

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

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

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

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

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?

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)

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

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?

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

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 • 3rd party tools and libraries • Principles learned from exercise could apply to OS • Fundamentally an issue untrusted lower layers

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.

15. Questions?

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