p im: scalable and hardware-independent firmware testing
TRANSCRIPT
P2IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling
Bo Feng, Alejandro Mera, and Long LuNortheastern University
USENIX Security 2020
Microcontrollers (MCU) are ubiquitous
Smart light bulb Pulse oximeter
DronePLC 3D printer
Fitness tracker
2
• MCU is a single-chip computer
• 28.1 billion MCUs are sold worldwide in 2018*
*https://www.statista.com/statistics/935382/worldwide-microcontroller-unit-shipments/
MCU vulnerabilities
3
Arbitrary code execution• Consequences• Digital damage (e.g., privacy leakage)• Physical damage (e.g., human injury)
• Most vulnerabilities are from firmware
MCU firmware
4
Firmware
Application
Library
OS (opt.) Driver
• Whole software stack of the MCU
• Bugs appear in all components
Firmware testing
• Fuzzing can effectively find bugs on desktop programs
• As firmware has similar bugs to desktop programs, we test firmware with fuzzers
• Firmware can be tested either on a device or emulator
5
Because of limited resources on MCU, on-device fuzzing is not feasible
Emulator-based firmware testing
6
Processor
Peripheral 1
Peripheral 2
Peripheral n
Peripheral
Interface Register Interrupt
Processor
Peripheral 1
Peripheral 2
Peripheral n
Peripheral
Interface Register Interrupt
Emulator-based firmware testing
7
• Not emulated because peripherals are diverse and hard to emulate
• Firmware cannot boot
Existing solution (1)
8
Processor
Peripheral 1
Peripheral 2
Peripheral n
Peripheral
Interface Register InterruptPeripheral emulation:
Emulate peripheral hardware by software components in the emulator
Incomplete support for peripherals, significant manual efforts
Existing solution (2)
9
Processor
Peripheral 1
Peripheral 2
Peripheral n
Peripheral
Interface Register Interrupt Hardware-in-the-loop emulation:
Use real peripheral hardware to handle peripheral access in the emulator
Rely on real hardware, slow, unscalable
Existing solution (3)
10
Processor
Peripheral 1
Peripheral 2
Peripheral n
Peripheral
Interface Register InterruptPartial emulation:
Replace peripheral-dependent firmware code with software stubs that have the same functionalities
Unable to test peripheral-dependent code, significant manual efforts
Design goals
11
Automatic
• A great number of MCU devices need to be tested
• Limited time and money budget for testing
• Human efforts can be minimized
Hardware-independent
• Firmware is tested in the emulator
• Faster and easier to automate
Peripheral-agnostic
• Peripherals are diverse
• Handle peripherals using a uniform approach
• Given a new peripheral, no extra effort is needed
Scalable
• Multiple fuzzerinstances can run in parallel
• Improve code coverage
Observation
• Peripherals are diverse in terms of type and functionality, but interface is not
12
Peripheral InterfaceType Many 2Functionality Many 3Diversity High Low
Key idea
13
• Treat peripherals as black box
• Abstract a model to handle register access and interrupt firing for a wide range of peripherals
Processor
Peripherals
Register Interrupt
CR SR
DR C&SRINT
Interface
Comparison with state-of-the-art
14
Approaches Automatic Hardware-independent
Peripheral-agnostic Scalable Existing work
Peripheral emulation ! ✓ ! ✓ GNU MCU Eclipse QEMU (2015), PartEmu (Usenix ’20)
Hardware-in-the-loop emulation ! ! ✓ !
Avatar (NDSS ’14), Prospect (Asia CCS ’14), Surrogates (WOOT ’15), Charm (Usenix ’18)
Partial emulation ! ✓ ✓ ✓ Firmadyne (NDSS ’16), HALucinator (Usenix ’20), PartEmu (Usenix ’20)
P2IM (our work) ✓ ✓ ✓ ✓
CrashingTest Cases
Processor Emulator Firmware Binary
Processor-peripheralInterface Model
P IM2
Fuzzer
Workflow
15
Interface modeling
16
How to model an interface?
Peripherals determine register value and interrupt-firing timing, but peripherals are considered as black box
Registers are categorized by their functionalities and handled accordingly
Interrupts can be fired at any time. We use a fixed frequency
Manual
Register categories
17
Control register (CR)
Status register (SR)
Data register (DR)
Control-status register (C&SR)
Interface modeling (2)
18
Given a firmware, how to identify the interface needs to be modeled?
Registers are identified and categorized by monitoring access to the memory-mapped peripheral region
Interrupts are detected by monitoring the interrupt controller
Automated
CrashingTest Cases
Processor Emulator Firmware Binary
Processor-peripheralInterface Model
P IM2
Fuzzer
Workflow
19
Existing fuzzers can be used without modification
Evaluation
• 70 sample firmware for essential peripheral operations• E.g., data transmission through USART peripheral
20
ADC
GPIO
I2C
PWD
DAC
SPI
USART
Timer
Peripheral
STM32 F103
NXP MK64F
Atmel SAM3X
MCU OS
Results
• The majority of firmware boot and perform essential peripheral operations normally• 79% test cases pass
• The accuracy of register categorization is between 76% and 92%
21
Accuracy is comparable on different peripherals
Fuzzing
• Fuzz-test 10 real-world firmware • Drone, Robot, Gateway, PLC, etc.
22
Fuzzing performance
• The accuracy of register categorization is between 69.6% and 100%• Speed and basic block coverage:
23
Firmware Speed (# tests/s) Basic block coverage Coverage improvement
Drone 17.2 58% 7x
CNC 18.0 70% 26x
Steering C. 32.3 20% 30x
…
Fuzzing result
• Detect 7 unique bugs, all of which are• Previously unknown• Remotely exploitable• Reproducible on real device
24
Firmware Unique bugs Bug nature
PLC
3 Incorrect Type Cast
1 Integer overflow
1 Incorrect Conversion between Numeric Types
Gateway 1 Buffer overflow
Heat Press 1 Buffer overflow
Summary
• Propose P2IM, the first scalable and hardware-independent firmware testing framework• Design and implement a novel interface modeling mechanism• Fuzz-test 10 real-world firmware • Find 7 previously-unknown vulnerabilities
25
Code and Tested Firmware at:
https://github.com/RiS3-Lab/p2im
