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 sandboxing
4/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 layers
12/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 time in seconds
• Load latencies do not
impact usability
16/14