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 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

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

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 sandboxing4/14

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

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

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

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

Untrusted computing base: defending against malicious hardware

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

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

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 layers12/14

Hardware support for dynamic binary translation

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

Questions?

15/14

Performance

• Load latencies do not impact usabilityLoad time in seconds

16/14