1 / 31

Protecting Commodity Operating System Kernels from Vulnerable Device Drivers

Protecting Commodity Operating System Kernels from Vulnerable Device Drivers. Shakeel Butt*, Vinod Ganapathy*, Michael Swift ^ , Chih-Cheng Chang*. *Rutgers University, ^ University of Wisconsin, Madison. Take home message.

vmedina
Download Presentation

Protecting Commodity Operating System Kernels from Vulnerable Device Drivers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protecting Commodity Operating System Kernels from Vulnerable Device Drivers Shakeel Butt*, Vinod Ganapathy*, Michael Swift^, Chih-Cheng Chang* *Rutgers University, ^University of Wisconsin, Madison

  2. Take home message Vulnerable device drivers can be compromised to hijack control of commodity operating systems This talk New security architecture to contain vulnerable device drivers

  3. 1. Device drivers dominate OS code base • Large percentage of OS is device driver code • 3.1 million out of 5.4 million LOC in Linux • 35K different drivers with over 112K versions in Win XP.

  4. 2. Device drivers execute in kernel mode Applications Kernel Device Driver Device Device Driver Device Device Driver Device

  5. Vulnerable device driver Applications Malformed Input Kernel Device Driver Device

  6. 3. Device drivers are vulnerable • Wireless drivers exploits in WinXP & OS X. • BroadCom, D-Link, NetGear [Cache 06] • Intel Wireless 2200BG & 2915ABG [Bulygin 07] • OS X Atheros driver [Maynor 07] • Device drivers contain more bugs than kernel.

  7. Outline • Introduction • Background • Our Architecture • Evaluation • Summary

  8. Related Work • Driver isolation systems • Nooks [Swift 03] • SafeDrive [Zhou 06] • User-level drivers • Windows UMDF • Linux User-Level Device Drivers [Leslie 05] • Hybrid • Microdrivers [Ganapathy 08]

  9. Microdrivers Applications Kernel U-driver Device Driver Device K-Driver

  10. Benefit # 1: Reduced code in kernel U-driver Applications Kernel Device K-Driver Reduced in-kernel device drive code

  11. Benefit # 2: Compatibility U-driver Applications Kernel K-Driver Device Same interface with the Kernel

  12. Benefit # 3: Good performance U-driver Applications Kernel K-Driver Device Performance critical code

  13. Benefit # 4: Flexibility U-driver Applications Kernel int get_status(char*) K-Driver Device

  14. U-driver & K-driver Communication int get_status(char*) U-driver Applications Marshalling Buffer Kernel Marshalling Buffer get_status(arg) K-Driver

  15. Misplaced trust between U-driver & K-driver int get_status(char*) U-driver Applications kern_fptr = {injected code} Marshalling Buffer Kernel get_status(arg) K-Driver

  16. Solution: RPC Monitor U-driver Applications Kernel RPC monitor K-Driver Device

  17. Outline • Introduction • Background • Our Architecture • Evaluation • Summary

  18. RPC Monitor • Enforces • Data integrity constraints • Control flow policies • Data integrity constraints are extracted automatically using dynamic analysis. • Control flow policies are extracted automatically through static analysis.

  19. Enforcing data integrity constraints int get_status(char*) U-driver Applications Marshalling Buffer Kernel Marshalling Buffer RPC Monitor get_status(arg) K-Driver

  20. Inferring data integrity constraints U-driver Traces Training workload Logger U-driver Kernel Traces Daikon Data Integrity Constraints K-Driver Device

  21. Examples of data integrity constraints

  22. Enforcing control flow policies • Scenario 1: • Return from function call in U-driver • RPC Monitor ensures that control returns to the instruction following upcall instruction • Scenario 2: • U-driver calls a function in Kernel or K-driver • RPC Monitor ensures that the function call is allowed according to statically extracted policy

  23. Outline • Introduction • Background • Our Architecture • Evaluation • Summary

  24. Experiment Setup • QEMU 0.9.1 & VMWare Workstation 6 • Implemented in Linux 2.6.18.1 kernel • Ported 4 device drivers

  25. Goals of Evaluation • Effectiveness • Simulated attacks • Fault injection experiment • Performance

  26. Fault Injection Experiment Setup • Fault injector from SafeDrive [Zhou 06] • Types of faults • Removes assignment instructions • Changes if conditions • Changes loop counters • Two device drivers • 8139too • 8139cp

  27. Fault injection experiment Faults Crashed U-driver Applications Kernel RPC monitor System Log System Log K-Driver

  28. Performance Experiment Setup • Device drivers • Network drivers (8139too, 8139cp) • USB driver (uhci-hcd) • Workload for network drivers • TCP send • TCP receive • Workload for USB driver • Copy a file of 100MB

  29. Performance

  30. Summary • Reduction of trusted code in kernel • Good common-case performance • Compatible with Commodity OS • Able to detect large number of faults

  31. Thanks Questions?

More Related