Secure browsers, hardware support for binary translation
Download
Report
Transcript Secure browsers, 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 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