Micro control idsecconf2010
0 likes584 views
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.
Micro control idsecconf2010
- 1. Micro Control Attacking uC Applications Don A. Bailey (donb@isecpartners.com)
- 2. whois donb?
- 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
- 8. Why wouldn’t you PWN an uC?
- 9. Prior work? • Travis Goodspeed ▫ GoodFET, neighbor! • Josh Wright ▫ Killerbee!
- 10. Picking on Atmel AVR8
- 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
- 19. Typical AVR8 Stuff? • Interrupts • Atomic Execution (sort of ;-) • Stack • 32 8-bit registers • LSB • 8/16/32/64-bit integer support • Access to I/O mem • RISC
- 20. What doesn’t AVR8 have? • Security boundaries • Contexts (multiple stacks) • Concurrency • Segmentation/Paging • No atomic instructions (cmpxchg?) • Native 32/64-bit integer support • Exceptions ▫ Where‟s the Page Fault, yo?!
- 21. Let’s Talk Program Flow
- 22. Typical programmatic flow • Reset • Init • Main • somefunc
- 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…
- 24. From RESET -> main()
- 26. crt0 Copy of .rodata
- 28. Stack Dump After Call to main()
- 30. Function Call
- 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
- 38. Now, Let’s Have Some Real Fun
- 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
- 52. Format Strings • Current avr-libc has no %n support • No fun • But, kind of reasonable
- 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
- 60. We Pack and Deliver like UPS Trucks
- 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