250 likes | 383 Views
The 16 th European Symposium on Research in Computer Security (ESORICS), 12-14 Sep 2011, Leuven (Belgium). DriverGuard: A Fine-grained Protection On I/O Flows. Yueqiang Cheng , Xuhua Ding and Robert H. Deng. School of Information Systems Singapore Management University.
E N D
The 16th European Symposium on Research in Computer Security (ESORICS), 12-14 Sep 2011, Leuven (Belgium) DriverGuard: A Fine-grained Protection On I/O Flows Yueqiang Cheng, Xuhua Ding and Robert H. Deng School of Information Systems Singapore Management University
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 2
Data regions • I/O ports or MMIO • Driver buffers • kernel stacks • User-space regions • Device I/O Interfaces • I/O ports • Memory-Mapped IO (MMIO) • DMA Typical I/O Flow So many possible target interfaces and regions for attackers ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 3 3
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 device Application Driver No Good Existing Solutions ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 4 4
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 5
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 6
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 7
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 8
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 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 9
Device User Space Application Guest Kernel Driver Hypervisor with DriverGuard 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 10
Only code segmentsthat need to access the I/O data or issue I/O commands: • Havethe privilegeto 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 Our Approach in DriverGuard ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 11 11
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. • Command-PCB and Computation-PCB are original driver code; key-PCBs are introduced as library functions called by drivers. ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 12 12
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 13
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 14
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 Device Example with Typical Input Flow User Space • Initialization step • Context initialization • DriverGuard collects locations of PCBs • PCBs issue hypercalls to update • Devices I/O interfaces • Data regions Application Guest Kernel Driver with PCBs … Hypervisor with DriverGuard ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 15 15
Example with TypicalInput Flow (cont.) Driver buffer Device DMA buffer Data buffer User Space • Driver gets read request from user space Application Guest Kernel Request • A PCB issues hypercall to ask DriverGuard protecting DMA buffer Driver with PCBs … • A PCB issues command(s) to device • Update address of DMA buffer to device Hypervisor with DriverGuard ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 16 16
DMA buffer Encrypting Access grant Driver Execution Flow Plain text Device Plain text Data buffer Driver buffer Cipher text DMA buffer In PCB execution Example with TypicalInput Flow (cont.) User Space Application • Device uses DMA to transfer data into DMA buffer, and generates an interrupt Guest Kernel Driver with PCBs … • Getting the interrupt, a PCB accesses the Input (raw) data Hypervisor with DriverGuard ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 17 17
Encrypting Decrypting Device Driver Execution Flow Plain text DMA buffer Data buffer Driver buffer Cipher text Cipher text DMA buffer In PCB execution Example with TypicalInput Flow (cont.) User Space Application • A PCB may do computation operations on data Guest Kernel Driver with PCBs … Hypervisor with DriverGuard ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 18 18
Data buffer Device Driver buffer Driver buffer Data buffer DMA buffer Example with TypicalInput Flow (cont.) User Space • Data movement • Do not need to know the content of data • Not need PCBs Application Guest Kernel Driver with PCBs … • Finally data is transferred into user space Hypervisor with DriverGuard • The data is decrypted ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 19 19
Cipher text Plain text • If the PCB is scheduled off CPU • DriverGuard sets the data region(s) inaccessible • DriverGuard prepares a fake kernel stack to prevent attackers getting sensitive information from stack Cipher text Plain text • If the PCB is scheduled on CPU • DriverGuard sets the data region(s) accessible. • DriverGuard restores the original kernel stack Encrypting Plain text On CPU Driver Execution Flow Out of PCB execution Decrypting Access Denied Access Grant Off CPU In PCB execution PCB Execution Escorting ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 20 20
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 21
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 22
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 23
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 24
Thanks, Questions? ESORICS 2011 DriverGuard: A Fine-grained Protection On I/O Flows 25 25