This document discusses security issues with microcontrollers (uCs). uCs are commonly used in devices like cars, medical implants, and infrastructure systems. The Atmel AVR8 uC architecture is examined in depth. Issues discussed include weak randomness for crypto, race conditions due to lack of concurrency controls, buffer overflows enabled by the Harvard architecture separating code and data, and attacks involving NULL pointers, uninitialized memory, and dereferencing memory beyond physical limits. Exploiting these issues could allow taking control of uC firmware to potentially manipulate connected devices and systems.
3. What’s this uC thing all about?
• Single integrated computer
• Processor, volatile, non-volatile storage
▫ All In One
• Can drive many peripherals
• Easily programmable
• Field update/upgrade capability
• Personalization (EEPROM)
4. No, really… Why do I care?
• Your car
• Implanted medical devices
▫ WBAN (Wireless Body Area Network)
• Crops monitoring (hydro/aero/enviro-ponics)
• Infrastructure monitoring (SCADA, etc)
• “Smart Dust”
• Access controls (RFID, biometrics, etc)
5. Now with More Networking!
• Bluetooth
• USB
• 802.11
• 802.15.4
• RFID
• DECT
• GSM
6. Security?
• Some tamper resistance
• Hardware security
• From a software point of view?
▫ Crypto support
▫ …?
7. OODA Loop?
• Field upgrades are rare
▫ But getting more common
▫ ST M24LR64 Dual EEPROM (Leet!!)
• Most firmware is legacy code
• Spot updates for new functionality / peripherals
• Mostly written in C, C++, and/or ASM
11. Lots of uC out there, but…
• Popular with hackers and engineers
• Free toolchain (gcc based)
• Free IDE (AVR Studio 4)
• No Soldering necessary
• Relatively cheap dev tools
▫ AVRISP mkII (~30 USD)
▫ AVR JTAGICE mkII
(good deals from Arrow Electronics)
14. Typically included in AVR8
• ALU
• Flash
• SRAM
• EEPROM
• Peripheral support (USART, SPI, I2C, TWI, etc)
16. That’s right, it’s Harvard
• Separate Data and Code lines
• Code always retrieved from Flash
• Data always retrieved from SRAM
• Flash can be written in software
▫ Typically Boot Loader Support
▫ Fuses determine this
▫ Some AVR8 don‟t support this
17. Point?
• Attack data, not instructions
• Return-to-whatever (ROP :-P)
• Easier! Less data to inject (typically)
• Takes longer
• That‟s what GoodFET is for
▫ Snatch one Smart Dust sensor
▫ GoodFET
▫ Analyze code
▫ Build ROP strategy
▫ Own 100 more remotely
23. On startup
• AVR sets PC to OxOO in Flash
• OxOO = Reset Vector
• JMP to init in crtO
• Init does stuff…
• Call main
• Do stuff…
• Call somefunc
• Do more stuff…
34. Four Main Points Demonstrated…
• Function conventions are typical
▫ Optimization may minimize this
• Code Layout
• Data Layout
• Atomic Code Sections
35. Code Layout in Flash
• Interrupt Vectors at OxOO
• RESET Vector at OxOO
• Main Application Code
• Data (???)
• Boot Loader Section
▫ Can write to Flash (if Fuses allow) for field
updates
36. Data Layout in SRAM
• Registers at OxOO
• I/O Memory at Ox2O
• Extended I/O Memory
• Data (copied from Flash) at Ox1OO
• BSS
• Heap
• Stack
• ??? ;-)
37. Atomicity
• CLI used
• SREG can be accessed via SRAM (I/O memory)
• 1 CPU Cycle to write to SREG
• Flow:
▫ Save a copy of SREG
▫ Clear Interrupt Bit in SREG
▫ Perform uninterrupted action
Write to low byte of SP
Write to SREG (old state with interrupt bit set)
Write to high byte of SP
39. Entropy? What entropy?
• Randomness is very weak
• Crypto hurt as a result
• Pools can be accumulated
▫ “True Random Number Generator On an Atmel
uC” – IEEE Paper
• 8 Random Bits using RC oscillator
▫ Per second!!!
40. Race Conditions
• No semblance of context switching
▫ TinyOS/Contiki simulate it
• Critical Sections secured through CLI
• Attack these sections
▫ Overwrite SREG; enable Interrupts
• Use Interrupts to cause unexpected behavior
41. Return Value Checks
• Snprintf returning <=O or >= sizeof buf?
• Logic Issue
• Always a problem
42. memcpy and Friends
• Latest avr-libc
• Don‟t test for negative size values
• No option to “secure” with CLI
▫ Interruptable
▫ Oops…Where‟d my SP go?! ;-)
43. Buffer Overflows
• Easy as pie
• Instruction address in mem is /2
• Return Oriented Programming
▫ Get those Registers set up correctly!
• Force a jump to the Boot Loader
• Instant Flash update (simulate field update)
• Can be triggered remotely
• AVR doesn‟t know the difference between you
and developer
44. Frame Pointer Overwrite
• Standard FP overwrite
• Point stack to attacker controlled data
• Next frame has the RET
• FP saved LSB first
45. Setjmp
• Obvious target
• Often used
• Makes up for lack of exceptions
• Saves entire program state
• Overwrite all registers
• Overwrite PC
46. Integer Overflows
• Work as expected
• 8-bit registers
• 16-bit native instructions
• Easy to wrap OxFFFF
47. Integer Promotion
• Normal integer promotion
• Unsigned -> Signed = No Sign Extension
• Signed -> Signed = Sign Extension
• Stop using „char‟ for everything ;-)
• Lots of 8-bit networking protocols
▫ 8-bit size fields
▫ Promoted to int during packet ingestion
▫ Oops!!
48. Heap Overflows
• Heap Struct consists of { size, Next* }
• Next* points to the next free heap chunk
• Adjacent chunks are combined
• No function pointers
• Easily mangle data
• Next* doesn‟t have to point to Heap
• Heap data isn‟t zeroed on free()
• Easy way to create pseudo stack frames
• ROP Helper!
49. Double Free
• Latest avr-libc free() doesn‟t check
• Any address can be used (except NULL)
• Free() will happily overwrite first 2 bytes with
▫ Next*
• Add it to the free list ;-)
• Can stealthily force malloc() to return
(void*)OxOO
• Write direct to Registers, I/O memory, etc
• ROP Helper!!
50. “Segment” Collision
• Heap is allocated slightly under stack
• Stack is dynamic!!!
• BSS is adjacent to Heap
• .rodata isn‟t Read Only! Adjacent to BSS
• One big happy family!
51. Uninitialized Variables
• Allocate a large Heap chunk
• Spray with OxAABB
• Stack decends into Heap
• Bewm!
• Example code at:
▫ http://pa-ri.sc/uC/dangle.tar.bz2
53. NULL Pointer Dereferences
• There are no privilege rings, but still useful
• Functions like malloc() still return NULL
• (void*)OxOO points to Registers in SRAM
• NULL deref is a very good thing
• Like free() bug, instant access to Regs, I/O Mem
• On the flip side…
▫ ??? ;-)
54. Beyond Memory
• Deref beyond physical memory addresses?
• Example: ATmega644P
▫ 4096 bytes SRAM
▫ Total 4196 addressable bytes
With registers, I/O memory
• Ox1OFF should be highest addressible address
58. There is no Page Fault on AVR8
• Memory faults cannot occur
• For program safety, don‟t RESET
• Read AND Write support
• Just wrap addresses back to (void*)OxOO
• Overwriting past end of PHYSMEM = start of
PHYSMEM
• i.e. Ox11OO = OxO1OO
• How convenient ;-)
• Overwrite EVERYTHING ANYWHERE
59. Example code?
• See the memdump application
▫ Runs on any AVR8 with USART
▫ http://pa-ri.sc/uC/memdump.tar.bz2
• Code tested on 10 different uCs in the AVR
family
▫ ATtiny
▫ ATmega
61. Summary?
• Ripe environment for application vulnerabilities
• Little protection schemes
▫ Except solid auditing and a tight SDLC
• Lots of legacy code in the field
• Lots of important devices
62. Special thanks…
• Jim Geovedi
• Y3dips
• Kendi Demonic
• Abdul Azis
• Dhillon Kannabhiran
• iSEC Partners
• Nick DePetrillo
• Mike Kershaw
• Travis Goodspeed
• Josh Wright