280 likes | 450 Views
VIPER : Verifying the Integrity of PERipherals ’ Firmware Yanlin Li , Jonathan M. McCune, and Adrian Perrig Carnegie Mellon University. Motivation. Triulzi injected Malware into a Tigon NIC to eavesdrop on traffic (2008)
E N D
VIPER: Verifying the Integrity of PERipherals’ Firmware Yanlin Li, Jonathan M. McCune, and Adrian PerrigCarnegie Mellon University
Motivation • Triulzi injected Malware into a Tigon NIC to eavesdrop on traffic (2008) • Malware on NIC deploys malicious code into GPU, causing GPU to store and analyze data sent through NIC PCI Bus OS
Motivation • Chen injected key logger into Apple Aluminum keyboard firmware (2009) • Buffer overflow vulnerability in Broadcom NIC was disclosed (2010)
Malware on Peripherals • Eavesdrops on data handled by peripherals • Modifies executable programs or scans data in main memory through DMA if IOMMU is not perfectly configured • Spread malware to other peripherals through DMA • Collaboration with malware on other peripherals through communication through PCI bus
Challenge & Problem Definition • Open challenge to detect malware on peripherals • Limited memory and computational resources on peripherals • Hardware-based protection is expensive and impractical Verifying the integrity of peripherals’ firmware, and guaranteeing absence of malware
Contributions • Systematically analyze malware features on computer peripherals • Propose VIPER, a software-only primitive to verify integrity of peripheral devices’ firmware • Propose a novel attestation protocol that prevents all known software-only attacks • Fully implement VIPER on a Netgear GA620 network adapter on an off-the-shelf computer
Outline • Motivation • Challenge & Problem Definition • Assumptions & Attacker Model • Software-Based Root of Trust • VIPER • Implementation • Evaluation • Related Work • Conclusion
Assumptions & Attacker Model • Assumptions • Physical attacks are out of scope • Verifier Program on host CPU is protected & trusted • Verifier program knows peripherals’ information • Attacker Model • Compromises peripherals’ firmware • Controls remote machines to assist the compromised device • Cannot break cryptographic primitives
Software-based Root of Trust • Verifier verifies checksum & timing results • Malicious code or operations either result in invalid checksum or require longer computation Peripheral Host CPU Verification Code Verifier Code 1. nonce 2. Untampered environment and Compute Checksum Checksum Simulator Checksum Function 3. checksum Communi-cation Func Expected Firmware 4. hash Timer Hash Func
Proxy Attack • Proxy Helper: a remote machine • Has a copy of correct firmware • Computes expected checksum for untrusted device 1. Random Nonce 2. Random Nonce Verifier Untrusted Device Proxy Helper 4. Checksum Result 3. Checksum Result
VIPER: Challenges • Local Proxy Attack • Peer-to-peer communication between two peripherals through DMA • A faster peripheral helps a slower peripheral • Verify faster peripheral first! • Remote Proxy Attack • E.g., a NIC can communicate with a remote proxy helper over Ethernet How to defend against a Remote Proxy Attack?
Software-based Root of Trust • Verifier verifies checksum & timing results • Malicious code or operations either result in invalid checksum or require longer computation Peripheral Host CPU Verification Code Verifier Code 1. nonce 2. Untampered environment and Compute Checksum Checksum Simulator Checksum Function 3. checksum Communi-cation Func Expected Firmware 4. hash Timer Hash Func
Latency-Based Attestation Protocol Normal Case: cpu cpu Tsend Time line Trecv Host CPU cksum nonce Peripheral Overhead per Tcomp cpu cpu Proxy Attack: Tsend Trecv Time line Host CPU cksum nonce Peripheral cksum nonce Proxy Helper per helper per Tsend Tcomp Trecv
Can we defend against a proxy attack all the time? • Parameters • Computation time on proxy helper: • Communication time of a proxy attack: • Checksum computation time: • Timing accuracy on host CPU: proxy proxy Tcommunication Tcomp= zero peripheral Tchecksum cpu Taccuracy proxy Tcommunication > peripheral Tchecksum _ peripheral proxy proxy Tcommunication Tchecksum Toverhead = proxy cpu Toverhead Taccuracy >
Idle Times Between Multiple Nonce-Checksum Pairs • Multiple nonce-checksum pairs to check all memory locations • Peripheral is idle between two nonce-checksum pairs Idle time Time line Host CPU Peripheral cksum1 cksumn cksum2 nonce1 nonce2 …… computation
Improvement • Host CPU sends next nonce before the peripheral returns checksum • The new nonce determines which checksum to return • Proxy helper cannot know which checksum to return, so has to return all checksum states that have been updated • Increases overhead of a proxy attack computation computation Time line Host CPU cksum1 cksumn cksum2 nonce1 nonce2 nonce3 …… Peripheral computation
VIPER • Latency-based attestation protocol • Multiple nonce-response pairs • From faster peripheral to slower peripheral Host CPU Peripherals Verification Code Verifier Code nonce3 nonce2 nonce1 Checksum Simulator Checksum Function Untampered environment and Compute Checksum Checksum N checksum1 … Communication Func Expected Firmware hash Timer Hash Func
Implementation • PCI-X Netgear GA620 NIC • Two MIPS Microcontrollers (200 MHz) • 4 MB SRAM • Open Firmware Version 12.4.3 • Checksum and communication code: 656 MIPS instructions • SHA-1 Hash Function: 2 KB binary • Sun Fire rack-mount server • Single-core AMD Opteron Processor • 2 GB RAM, Two PCI-X slots • Linux 2.4.18
Netgear GA620 NIC Scratch-Pad Mem (16 KB) Scratch-Pad Mem(8 KB) CPU A CPU B SRAM (4 MB) Checksum Benign code Malicious code
Verification Procedure 2. Verify checksum and hash func 1. Verify entire scratch pad memory PC stays within the trusted code Scratch-Pad Mem (16 KB) Checksum Scratch-Pad Mem(8 KB) Hash Func Checksum CPU A CPU B 3. Compute Hash over Firmware Contents • No hash func Only verify Scratchpad memory SRAM (4MB) CPU A and CPU B cannot access each other’s scratch-pad memory Attestation can start from either A or B
Checksum Design • 32 checksum blocks • All 31 available registers are used • No extra registers for malicious operations • Strong-ordered AND, XOR operations • Includes PC, DP, other checksum states, memory contents • Each checksum block fits into a cache line • Instruction Cache: 64 Bytes (16 MIPS instruction) • Additional code will cause more cache miss
Evaluation • Various Attacks • Ethernet-Based Proxy Attack • Data Pointer (DP) Forging Attack • Program Counter (PC) Forging Attack • We implemented all three attacks • Real Ethernet-Based Proxy Attack: 43 us • Theoretical Fastest Proxy Attack over 1 Gbps Ethernet: 1.2 us • DP/PC Forging Attack: 5 extra MIPS instructions and 2 more cache misses
Evaluation Results Various Attacks Threshold (4.5% over benign case) Benign Case
Related Work • L. Duflot, Y.-A. Perez, and B. Morin. Run-time firmware integity verification: what if you can not trust your network card? In CanSecWest, 2011. • Y. Li, J. M. McCune, and A. Perrig. SBAP: Software-Based Attestation for Peripherals. Trust 2010. • F.L. Sang, V. Nicomette, Y. Deswarte, and L. Duflot. Atteaues DMA peer-toppeer et contremeasures. SSTIC, 2011. • K. Chen. Reversing and exploiting an Apple firmware update. In Black Hat, 2009. • L. Duflot, Y.-A. Perez, G. Valadon, and O. Levillain. Can you still trust your network card? CanSecWest, 2010. • A. Seshadri, A. Perrig, L. van Doorn, and P. Khosla. SWATT: SoftWare-based ATTestation for embedded devices. Oakland, 2004. • M. Shaneck, K. Mahadevan, V. Kher, and Y. Kim. Remote software-based attestation for wireless sensors. ESAS, 2005. • A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doorn, and P. Khosla. Pioneer: Verifying Integrity and Guaranteeing Execution of Code on Legacy Platforms. SOSP, 2005. • C. Castelluccia, A. Francillon, D. Perito, and C. Soriente. On the difficulty of software-based attestation of embedded devices. CCS. 2009. • A. Perrig and L. van Doorn. Refutation of “on the difficulty of software-based attestation of embedded devices”. http://sparrow.ece.cmu.edu/group/pub/perrig-vandoorn-refutation.pdf, 2010.
Conclusion • Detecting malware on peripherals’ firmware becomes increasingly important • Extend previous software-based root of trust mechanisms to defend against proxy attacks • Implementation & evaluation on a Netgear GA620 NIC • Anticipate that these techniques will make software-based root of trust practical on current platform
Thank you for your attention! Q & A Email: yanlli@cmu.edu