Source-linked AI summary
Code injection attacks on harvard-architecture devices
Aurélien Francillon, Claude Castelluccia
TL;DR
The paper addresses the belief that Harvard-architecture sensors cannot suffer remote code injection because code and data memories are separated. It combines fake-stack injection with existing gadgets to copy arbitrary malware into program memory. The resulting code is persistent, and the attack can be extended into a self-propagating worm, although ASLR remains vulnerable to brute-force attacks and authentication does not completely prevent propagation.
Problem
Harvard memory separation, small packets, and limited memory were believed to make remote code injection impossible on Mica-family wireless sensors.
Method
The attack injects a fake stack byte-by-byte, uses existing gadgets and meta-gadgets, and copies malware from data memory into program memory.
Results
The paper demonstrates persistent arbitrary-code injection on Micaz sensors and shows how the injected malware can become a self-propagating worm.
Takeaways & Limitations
The attack can take control of wireless sensor networks, enabling eavesdropping, configuration changes, or conversion of the network into a botnet.
Takeaways & Limitations
ASLR would remain vulnerable to brute-force attacks in the sensor’s limited address space, while packet authentication does not completely prevent code injection or propagation.
Abstract
from arXiv · showhide
Harvard architecture CPU design is common in the embedded world. Examples of Harvard-based architecture devices are the Mica family of wireless sensors. Mica motes have limited memory and can process only very small packets. Stack-based buffer overflow techniques that inject code into the stack and then execute it are therefore not applicable. It has been a common belief that code injection is impossible on Harvard architectures. This paper presents a remote code injection attack for Mica sensors. We show how to exploit program vulnerabilities to permanently inject any piece of code into the program memory of an Atmel AVR-based sensor. To our knowledge, this is the first result that presents a code injection technique for such devices. Previous work only succeeded in injecting data or performing transient attacks. Injecting permanent code is more powerful since the attacker can gain full control of the target sensor. We also show that this attack can be used to inject a worm that can propagate through the wireless sensor network and possibly create a sensor botnet. Our attack combines different techniques such as return oriented programming and fake stack injection. We present implementation details and suggest some counter-measures.
1. INTRODUCTION
The paper challenges the belief that remote code injection is impossible on Harvard-architecture sensor networks by presenting a persistent malware-injection attack and worm design for Mica motes.
- Motivation: Harvard architecture separates code and data memories, preventing standard stack-injected code from executing on Mica sensors.This made remote exploitation widely regarded as difficult or impossible.
- Motivation: Prior node-compromising work targeted Von Neumann sensors or produced only transient attacks using instructions already present in program memory.Permanent injection is more powerful because it can give an attacker full control.
- Contribution: The attack injects arbitrary malware by building a fake stack in data memory, executing existing gadgets, and copying the malware into program memory.The injected code then executes from program memory.
- Contribution: The injected malware is persistent, remaining in program memory even after the sensor resets.A self-propagating module can convert the malware into a worm.
- Evaluation: The attack was implemented and tested on Micaz sensors, with implementation details and prevention measures presented.
2. ATMEL AVR-BASED SENSOR
Micaz uses an Atmel AVR Atmega128 with physically separated program and data memories, but its bootloader can remotely rewrite program memory through self-reprogramming.
- Platform: Micaz targets an Atmel AVR Atmega128 8-bit microcontroller clocked at 8MHz with an IEEE 802.15.4-compatible radio.
- Architecture: The modified Harvard architecture separates program and data memories while permitting program modification under particular circumstances.The CPU executes only from program memory and writes only to data memory under normal operation.
- Architecture: AVR instructions LPM and SPM copy bytes between program and data memory, with SPM restricted to bootloader code.SPM enables remote configuration of a new application through the bootloader.
- Memory organisation: Program memory stores executable instructions in internal flash, which is divided into application and bootloader sections and supports self-reprogramming from the bootloader.
- Memory organisation: Data memory contains registers, I/O, and 4 KBytes of physical SRAM, while EEPROM and external flash provide separate persistent-storage functions.The data address space directly exposes registers and I/O because the microcontroller has no MMU.
- Bootloader: Remote updates are operationally important because deployed nodes are impractical to collect and physically reprogram.The bootloader changes the running program image after a remote request.
- Bootloader: The bootloader copies selected external-flash images to RAM in 256-byte pages and then writes them to program memory with SPM.
- Assumptions: The attack assumes every node has a bootloader, but does not require a remote code-update protocol; if such a protocol exists, its images are assumed authenticated.
3. ON THE DIFFICULTY OF EXPLOITING A SENSOR NODE
Sensor-node exploitation is difficult because Harvard memory separation blocks execution from data memory, while small packets and constrained programs limit injection and gadget-based attacks.
- Conventional exploitation: Traditional buffer overflows inject code into the stack and execute it, relying on writable data memory also being executable.
- Harvard constraints: Mica-family sensors separate code and data memories, and their program counters cannot address data memory, preventing these standard injection attacks.
- Resource constraints: TinyOS limits packet payloads to 28 bytes, making it difficult to inject useful code in one packet.
- Resource constraints: Limited memory produces size-optimized applications with limited functionality and frequent function inlining, complicating return-into-libc-style exploitation.
- Implication: Together, these architectural and resource constraints make remote exploitation of sensors highly challenging.
4. RELATED WORK
Related work includes non-executable-memory defenses, return-oriented gadget techniques, Von Neumann sensor attacks, and transient Mica attacks; this paper differs by enabling persistent arbitrary-code injection.
- Memory protections: NX-Bit and W⊗E mechanisms enforce memory regions as either writable or executable to prevent code execution from data memory.
- Protection bypasses: Return-into-libc and return-oriented programming bypass such protections by executing existing functions or instruction sequences instead of injected stack code.
- Von Neumann sensors: Earlier attacks on MSP430-based Telosb motes injected arbitrary-length bytecode into data memory, where Von Neumann execution made it executable.That approach is impossible on Harvard-architecture motes.
- Counter-measures: Hardware non-executable memory regions would complicate the attack but would not make it impossible.
- Transient Mica attacks: A prior Mica2 transient attack used buffer overflows and existing gadgets to perform limited actions and propagate packets to neighboring nodes.
- Transient Mica attacks: The transient attack was limited by one small packet, available instruction sequences, and disappearance after packet processing or reset.
- This paper’s approach: This paper instead uses gadgets to copy injected code from data memory to program memory, requiring fewer specific instructions and producing persistent arbitrary malware.
5. ATTACK OVERVIEW
The attack uses existing instruction sequences and a fake stack to inject arbitrary malware into program memory despite small packets and separated memories. It builds the fake stack byte-by-byte, then invokes a reprogramming gadget to copy and execute the malware.
- System assumptions: The attack assumes Micaz nodes run identical TinyOS-based software, use bootloaders, expose a buffer-overflow vulnerability, and have known program memory.These assumptions define the target setting and the attacker’s required knowledge.
- Meta-gadgets: A meta-gadget chains existing program-memory gadgets to perform more elaborate actions without requiring a Turing-complete gadget set.The paper uses meta-gadgets rather than directly executing injected code through return-oriented programming.
- Reprogramming: The Reprogramming meta-gadget uses bootloader instructions and stack-provided variables to copy malware from data memory into program memory.The bootloader’s page-copy function cannot be invoked alone because its code is deeply inlined, motivating the chained design.
- Byte-by-byte injection: Because packets are limited to 28 bytes, the attacker injects the fake stack byte-by-byte into unused data memory using an Injection meta-gadget.Each crafted packet writes one byte, and repeated packets reconstruct the complete fake stack at a chosen address.
- Attack sequence: After reconstructing the fake stack, the attacker invokes the Reprogramming meta-gadget to copy the malware into program memory and execute it.The procedure repeats injection and software reboot steps before the final reprogramming invocation.
- Reboots: Software reboots restore consistent program state while preserving the powered data-memory region containing the injected fake stack.The preserved memory enables bytes recovered across successive reboots to accumulate into the complete payload.
6. IMPLEMENTATION DETAILS
The implementation exploits a packet-reception vulnerability, constructs Injection and Reprogramming meta-gadgets from existing gadgets, and uses a fake stack to install malware persistently in program memory.
- 6.1 Buffer overflow exploitation: The attack begins by exploiting a vulnerable packet-reception routine, illustrated with a buffer overflow that redirects control flow to an existing gadget.The example overflows a 4-byte buffer and overwrites the saved return address.
- 6.2 Meta-gadget implementation: The Injection meta-gadget chains three gadgets to copy one attacker-supplied byte from the stack to a chosen data-memory address.The chain loads the destination and byte, moves the address into the store registers, and performs the write.
- 6.2 Meta-gadget implementation: The Reprogramming meta-gadget uses three bootloader gadgets to load fake-stack parameters, erase a program-memory page, and flash the malware.It can copy one page per execution; larger malware requires multiple executions.
- Automating the meta-gadget implementation: A static analyzer for Avrora collects available gadgets and searches for chains implementing the desired meta-gadget, outputting candidate payloads.The implementation depends on the node’s binary, including compiler version, flags, and available gadget addresses.
- 6.6 Turning the malware into a worm: The Reprogramming meta-gadget depends only on bootloader code and therefore works with any application using the same bootloader.The injected malware can subsequently self-propagate as a worm.
7. POSSIBLE COUNTER-MEASURES
The paper evaluates counter-measures against its attack, finding that existing protections are constrained by sensor hardware, software, and memory characteristics. Memory cleanup can block persistence across reboots but adds overhead and does not address every attack path.
- The attack first exploits a software vulnerability to smash the stack, then uses gadgets to inject persistent data into program memory.
- Software vulnerability Protection.: Safe TinyOS enforces array-bound checks, but manual instrumentation leaves protection vulnerable to human error and other software vulnerabilities.
- Stack-smashing protection.: Stack canaries prevent return-address overwriting, but implementing them on constrained sensors is challenging and no AVR implementation currently exists.
- Data injection protection.: Reinitializing all data memory on reboot prevents storing attack data across reboots, but incurs overhead and does not stop attacks that avoid reboot-based restoration.
- Data injection protection.: Applications that store their own data in memory could let attackers store the fake stack without the Injection meta-gadget, defeating the presented defense.
- Gadget execution protection.: ASLR is ineffective in small monolithic sensor address spaces, while randomized binaries remain vulnerable to brute-force attacks.
8. CONCLUSIONS AND FUTURE WORK
The paper concludes that permanent code injection into Harvard-architecture sensors is feasible and can be transformed into a self-propagating worm. It also identifies propagation conditions and large-scale infection effects as targets for future evaluation.
- The attack can take control of a wireless sensor network, enabling eavesdropping, configuration changes, or conversion of the network into a botnet.
- The main contribution is demonstrating permanent code injection into Harvard-architecture sensors and showing how injected code can self-replicate as a worm.
- Packet authentication and cryptography complicate but do not completely prevent injection; attackers may instead use compromised nodes and their keys to propagate malware.
- Future work will evaluate large-scale worm propagation, infection-packet loss and incomplete malware images, code-injection optimizations, and countermeasures.