VIPER: Verifying the Integrity of PERipherals’ Firmware

Yanlin Li, Jonathan M. McCune, and Adrian Perrig

Carnegie Mellon University

2

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

OS

PCI Bus

3

Motivation• Chen injected key logger into Apple Aluminum keyboard

firmware (2009)

• Buffer overflow vulnerability in Broadcom NIC was disclosed (2010)

4

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

5

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

6

Contributions

1. Systematically analyze malware features on computer peripherals

2. Propose VIPER, a software-only primitive to verify integrity of peripheral devices’ firmware

3. Propose a novel attestation protocol that prevents all known software-only attacks

4. Fully implement VIPER on a Netgear GA620 network adapter on an off-the-shelf computer

7

Outline

• Motivation• Challenge & Problem Definition• Assumptions & Attacker Model• Software-Based Root of Trust• VIPER• Implementation• Evaluation• Related Work• Conclusion

8

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

• Verifier verifies checksum & timing results– Malicious code or operations either result in

invalid checksum or require longer computation

9

Software-based Root of Trust

PeripheralHost CPU

Checksum Simulator

Expected Firmware

Timer

Checksum Function

Communi-cation Func

Hash Func

Verifier Code Verification Code

2.Untamperedenvironment

andCompute Checksum

1. nonce

3. checksum

4. hash

10

Proxy Attack

• Proxy Helper: a remote machine– Has a copy of correct firmware– Computes expected checksum for

untrusted device

1. Random Nonce

4. Checksum Result

UntrustedDeviceVerifier Proxy

Helper

2. Random Nonce

3. Checksum Result

11

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!

How to defend against a Remote Proxy Attack?

• Remote Proxy Attack– E.g., a NIC can communicate with a remote proxy

helper over Ethernet

• Verifier verifies checksum & timing results– Malicious code or operations either result in

invalid checksum or require longer computation

12

Software-based Root of Trust

PeripheralHost CPU

Checksum Simulator

Expected Firmware

Timer

Checksum Function

Communi-cation Func

Hash Func

Verifier Code Verification Code

2.Untamperedenvironment

andCompute Checksum

1. nonce

3. checksum

4. hash

13

Latency-Based Attestation Protocol

Time lineHost CPU

Peripheral

Tsend Trecvcpu cpu

Tcompper Overhead

Normal Case:

nonce cksu

m

helper

Time lineHost CPU

Peripheral

Proxy Helper

Tsend Trecvcpu cpu

Tsendper

Trecvper

Proxy Attack:

nonce

nonce

cksu

m

cksum

Tcomp

14

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:

proxyTcommunication > peripheralTchecksum

>cpu

Taccuracy

proxy

Toverhead

proxyTcommunication

peripheralTchecksum

cpuTaccuracy

proxyTcommunication

peripheralTchecksum

proxyToverhead =

_

proxyTcomp = zero

15

Idle Times Between Multiple Nonce-Checksum Pairs

Time lineHost CPU

Peripheral

nonce1 cksu

m1 nonce2

• Multiple nonce-checksum pairs to check all memory locations– Peripheral is idle between two nonce-

checksum pairs

Idle timecomputationck

sum

2

……

cksu

mn

16

Improvement

Time lineHost CPU

Peripheral

nonce1 cksu

m1nonce2

nonce3

• 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

computationcomputation

cksu

m2

……

cksu

mn

computation

• Latency-based attestation protocol– Multiple nonce-response pairs

• From faster peripheral to slower peripheral

17

VIPER

PeripheralsHost CPU

Checksum Simulator

Expected Firmware

Timer

Checksum Function

Communication Func

Hash Func

Verifier CodeVerification

Code

Untamperedenvironment

andCompute Checksum

hash

nonce1

checksum1

nonce2

nonce3

Checksum N

…

18

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

19

Netgear GA620 NIC

SRAM (4 MB)

CPU A CPU B

Scratch-Pad Mem(16 KB)

Scratch-Pad Mem (8 KB)

Checksum

Malicious codeBenign code

20

Verification Procedure

SRAM (4MB)

CPU A CPU B

Scratch-Pad Mem(16 KB) Scratch-Pad

Mem (8 KB)

Checksum

ChecksumHash Func

1. Verify entire scratch pad memory

PC stays within the

trusted code

2. Verify checksum

and hash func

3. Compute Hash overFirmware Contents

1. CPU A and CPU B cannot access each other’s scratch-pad memory

2. Attestation can start from either A or B

No hash func

Only verify Scratchpad

memory

21

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

22

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

23

Evaluation Results

Benign Case

Threshold (4.5% over benign case)

Various Attacks

24

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.

25

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

26

Thank you for your attention!

Q & A

Email: yanlli@cmu.edu