View
217
Download
0
Embed Size (px)
Citation preview
DriverGuard: A Fine-grained Protection On I/O
FlowsYueqiang Cheng, Xuhua Ding and
Robert H. DengSchool of Information SystemsSchool of Information Systems
Singapore Management UniversitySingapore Management University
The 16th European Symposium on Research in Computer Security (ESORICS), 12-14 Sep 2011, Leuven (Belgium)
2
Background and Motivations
• I/O flow protection is important and urgent– Sensitive information in I/O flows
• Biometric information (e.g., fingerprint template)• Password and credit card number• Sensitive document printing
– Device drivers lack of security functions• More loopholes due to the higher bug rate (compared
to other kernel code)
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 2
3
Typical I/O Flow
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 3
Data regionsI/O ports or MMIODriver bufferskernel stacksUser-space regions
So many possible target interfaces and regions for
attackers
Device I/O Interfaces
I/O portsMemory-Mapped IO (MMIO)DMA
4
No Good Existing Solutions
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 4
device Driver Application Remote server
Unprotected Terra/Overshadow
Data Flows in Alice’s Computer
TLS/SSL
Our goal: a generic solution to dynamically safeguard I/O flows from devices to
applications
The data in I/O flows from devices to applications are unprotected
5
Challenges
• Complex I/O subsystems– Different I/O interfaces– Complex interactions among drivers and kernels
• Powerful attacks – kernel rootkits have the same (highest) privilege
as the kernel to access any memory region• Directly access data regions• Device I/O control manipulation
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 5
6
Threat Model• I/O requests from user space are well-protected• Trusted hardware and System Management
Mode (SMM)• Trusted hypervisor (or VMM)
– Trusted booting guarantees load time integrity – IOMMU prevents malicious DMA transactions
• Devices drivers are benign drivers• The guest kernel is malicious
– The purpose of the malicious guest kernel is to steal sensitive information
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 6
7
Design Alternatives• Location Isolation – putting drivers into
driver domain or the hypervisor space– Large TCB decreases the security level of the
whole platform
• Execution Isolation – securing the driver’s execution in untrusted kernel space– Hard to isolate due to intensive driver-kernel
interactions– I/O subsystems which needs to be enclosed in
execution isolation dramatically increases the size of TCB
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 7
8
Features of Drivers• Most of the driver code is for housekeeping
purposes (e.g., error handling, resource allocation and cleaning up)
• Only a small portion of driver code dealing with I/O data transferring, and in these code– Only a few code blocks (e.g., decoding) need to
know the content to process the I/O data, or to issue command to devices
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 8
9
Features of Drivers (cont.)
• DriverGuard distinguishes code blocks, which issue commands or need to know the content of data, from other driver code
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 9
ehci_irq-> ehci_writel-> ehci_work-> … (several internal functions)
-> uvc_video_complete-> uvc_video_decode_isoc-> …
Issue command
Some of code blocks need to know the
content of data to do decode operations
USB-Camera Driver
10
DriverGuard Architecture
• DriverGuard works in the hypervisor space
• DriverGuard manages access permissions of device I/O interfaces and memory regions
• DriverGuard can intercept guest interrupts and exceptions
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 10
Hypervisor with DriverGuard
Device
Driver
Application
Guest Kernel
User Space
11
Our Approach in DriverGuard
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 11
Only code segments that need to access the I/O data or issue I/O commands:•Have the privilege to access the data and/or device I/O interfaces•Executions are safeguarded by the hypervisor
Enforce access control - Set Device I/O interfaces inaccessible
The data in data regions is encrypted
12
Privileged Code Block (PCB)• We call the high privilege code blocks in a
driver as Privileged Code Blocks (PCB)– Command-PCB: issue I/O commands– Computation-PCB: make computation on I/O data– Key-PCB: for cryptographic operations.
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 12
• Command-PCB and Computation-PCB are original driver code; key-PCBs are introduced as library functions called by drivers.
13
Key-PCB
• Key-PCB– Generate the driver's encryption key– Each driver has its own dedicated key-buffer in the
guest domain.– The key is used by computation-PCBs
• DriverGuard enforces access control on the key buffer.
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 13
14
Privileged Code Block (cont.)
• A driver’s PCBs are manually identified. • Requirements on PCB
– Stateless code• No extra data dependence
– Self-contained code• No extra code dependence. Do not call non-PCBs.
– No indirect call or indirect jump (e.g., no call using function pointer)
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 14
15
Access control enforcement - DriverGuard sets device I/O interfaces and updated data regions inaccessible•IOPL and I/O bitmap for I/O ports access control•Page Table Entry (PTE) for memory access control
Example with Typical Input Flow• Initialization step
– Context initialization• DriverGuard collects
locations of PCBs• PCBs issue hypercalls to
update – Devices I/O interfaces– Data regions
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 15
Hypervisor with DriverGuard
Device
Driver with PCBs…
Guest Kernel
Application
User Space
16
1. Driver gets read request from user space
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 16
Example with TypicalInput Flow (cont.)
Hypervisor with DriverGuard
Device
Driver with PCBs…
ApplicationUser
Space
DMA buffer
Driver buffer
Data buffer
Guest KernelRequesta) A PCB issues hypercall to
ask DriverGuard protecting DMA buffer
b) A PCB issues command(s) to device
I. Update address of DMA buffer to device
17
Example with TypicalInput Flow (cont.)
2. Device uses DMA to transfer data into DMA buffer, and generates an interrupt
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 17
Hypervisor with DriverGuard
Device
Driver with PCBs…
ApplicationUser
Space
DMA buffer
Driver buffer
Data buffer
Guest Kernel
3. Getting the interrupt, a PCB accesses the
Input (raw) data
DMA buffer
Plain text
Driver Execution Flow In PCB execution
Access grant
Encrypting
Plain text
Cipher text
18
Example with TypicalInput Flow (cont.)4. A PCB may do
computation operations on data
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 18
Hypervisor with DriverGuard
Device
Driver with PCBs…
ApplicationUser
Space
DMA buffer
Driver buffer
Data buffer
DMA buffer
Plain text
Driver Execution Flow In PCB execution
Decrypting Encrypting
Cipher text
Cipher text
Guest Kernel
19
5. Data movementDo not need to know
the content of dataNot need PCBs
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 19
Example with TypicalInput Flow (cont.)
Hypervisor with DriverGuard
Device
Driver with PCBs…
Application
User Space
Data buffer
6. Finally data is transferred into user space The data is decrypted
DMA buffer
Driver buffer
Data buffer
Driver buffer
Guest Kernel
20
PCB Execution Escorting
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 20
If the PCB is scheduled off CPUDriverGuard sets the data region(s) inaccessibleDriverGuard prepares a fake kernel stack to prevent attackers getting sensitive information from stack
Cipher text
Plain text
Plain text
Plain text
Cipher text
Off CPU On CPU
Driver Execution Flow
In PCB execution
Out of PCB execution
Decrypting Access Denied
Access Grant Encrypting
If the PCB is scheduled on CPUDriverGuard sets the data region(s) accessible.DriverGuard restores the original kernel stack
21
Implementation • The prototype of DriverGuard is built based
on Xen 4.0– Only add less 2k SLOC in Xen
• The total PCB code only account for 1% of the driver code (with Linux 2.6.31)
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 21
22
Evaluation
• We test the security of DriverGuard with several public rootkits (e.g., keyloggers)
• We test the performance overhead with five device drivers: keyboard, camera, fingerprint reader, printer, sound card
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 22
Keyboard input transfer
Camera waiting
Fingerprint collection
1 page print
Sound card open
Without DriverGuard
0.053ms 33.24ms 2.61s 15.74s 7.8 μs
With DriverGuard 0.138ms 33.38ms 2.63s 16.19s 12.3μs
Percentage 160.40% 0.42% 0.77% 2.86% 57.7%
23
Limitations
• The main drawback of our scheme is the need for manually discover PCBs from a driver
• DriverGuard is not suitable for high speed devices (e.g., network card, disk)– The data in network and disk I/O are derived data– They can be encrypted by applications.
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 23
24
Summary
• DriverGuard is a generic solution to dynamically protect I/O flows from devices to applications with low performance overhead
• DriverGuard can work jointly with user-space data protection schemes to safeguard the entire data lifecycle
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 24
25
Thanks, Questions?
ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 25