1 / 16

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

Secure web browsers, malicious hardware, and hardware support for binary translation. Sam King. Browser m otivation. Browsers most commonly used application today Browsers are an application platform Email, banking, investing, shopping, television, and more!

hiroko
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related