Memory Safety for Embedded Devices with nesCheck Daniele Midi Mathias Payer Elisa Bertino Dept. of Computer Science Dept. of Computer Science Dept. of Computer Science Purdue University Purdue University Purdue University West Lafayette, IN, USA West Lafayette, IN, USA West Lafayette, IN, USA [email protected] [email protected] [email protected] ABSTRACT terfaces. Common components include routing and packet Applications for TinyOS, a popular operating system for em- radio communication, sensor measurements, and storage. bedded systems and wireless sensor networks, are written The language used to program TinyOS applications is nesC, in nesC, a C dialect prone to the same type and memory a dialect of the C language optimized for the resource con- safety vulnerabilities as C. While availability and integrity straints of low-power embedded devices [13]. Because of the are critical requirements, the distributed and concurrent na- strict constraints in terms of memory, storage, and energy, ture of such applications, combined with the intrinsic un- neither TinyOS nor the underlying hardware provide any safety of the language, makes those security goals hard to memory protection or virtual memory mechanism between achieve. Traditional memory safety techniques cannot be processes or kernel and user-space. Moreover, the nesC lan- applied, due to the strict platform constraints and hardware guage makes it easy to write memory-unsafe code, inheriting differences of embedded systems. all the type and memory safety problems of C. We design nesCheck, an approach that combines static Memory corruption in the software running on a single analysis and dynamic checking to automatically enforce mem- node may allow an attacker to take over the node, read pri- ory safety on nesC programs without requiring source mod- vate data, or even disseminate incorrect data and degrade ifications. nesCheck analyzes the source code, identifies the the entire network. Note that embedded platforms do not minimal conservative set of vulnerable pointers, finds static have code injection protection or ASLR, so a holistic defense memory bugs, and instruments the code with the required like memory safety becomes even more important. More dynamic runtime checks. Our prototype extends the existing critically, since all the nodes run the same software image, an TinyOS compiler toolchain with LLVM-based passes. Our attacker may exploit a single vulnerability to take control of evaluation shows that nesCheck effectively and efficiently en- every node in the network. Concrete examples of such dev- forces memory protection, catching all memory errors with astating attacks have been shown for Harvard-architecture- an overhead of 0:84% on energy, 5:3% on code size, up to based sensor nodes such as the MicaZ motes [11], as well as 8:4% on performance, and 16:7% on RAM. Von Neumann-architecture-based ones such as the popular TelosB motes [15]. In these attacks, a well-crafted network packet sent to a vulnerable node can take control of the node 1. INTRODUCTION and propagate as a self-replicating worm to the entire net- Wireless Sensor Networks (WSNs) are deployed in criti- work through multi-hop communications [12, 14, 16, 32, 36]. cal, real-time applications, where availability and integrity All of these critical attacks would be prevented by enforcing are of paramount importance. WSN nodes are embedded memory safety. systems that often manage confidential information, such Existing memory safety techniques [26, 24, 4, 29] are not as private keys and aggregated data, making confidentiality applicable to embedded systems, nesC, or TinyOS, as they and integrity key requirements. However, the distributed are designed for general-purpose systems. Adapting them to and concurrent nature of WSN applications, together with embedded systems is unfeasible without extensive redesign. the intrinsic type and memory unsafety of C/C++, make it In fact, they have heavy requirements in storage, mem- hard to achieve these security goals. ory, presence of an MMU, and hardware memory-protection TinyOS [21] is an open source operating system designed mechanisms. However, embedded systems fundamentally for low-power wireless embedded systems, such as WSN differ from regular computing systems, having scarce mem- motes and smart meters [19]. TinyOS programs consist of ory, no MMU, no protection against code injection and code separate software components statically linked through in- reuse, and often not even a distinction between kernel-space and user-space. For example, widespread sensor motes like Permission to make digital or hard copies of all or part of this work for personal or the Memsic TelosB [23] only provide 10kB of RAM and classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation 48kB of program flash memory; previously proposed mem- on the first page. Copyrights for components of this work owned by others than the ory safety approaches result in significantly bigger code size author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or and more intensive memory usage. Moreover, the perfor- republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. mance degradation that many existing solutions impose is ASIA CCS ’17, April 02 - 06, 2017, Abu Dhabi, United Arab Emirates not acceptable for energy-constrained, real-time WSNs ap- c 2017 Copyright held by the owner/author(s). Publication rights licensed to ACM. plications. In fact, solutions such as CCured reported slow- ISBN 978-1-4503-4944-4/17/04. $15.00 downs ranging from 20% to 200% [26]. Given the resource DOI: http://dx.doi.org/10.1145/3052973.3053014 constraints, a straightforward porting of common implemen- 2. ADVERSARIAL MODEL tations for memory protection techniques to embedded sys- We assume that the attacker can inject and intercept ar- tems is infeasible. A tailored solution for memory and type bitrary packets in the network. We also assume that the ap- safety for TinyOS applications is therefore needed. plication has memory vulnerabilities known to the attacker. For TinyOS applications, the code for applications, li- She will exploit them to take control of a node by means braries, and operating system is entirely available at compile of code injection/reuse attacks or leak private information time. This allows us to effectively leverage whole-program from the node. The attacker has the power to compromise static analysis to ensure memory safety with a fallback to the integrity, availability, or confidentiality of the node. dynamic checking instrumentation if we run into aliasing Physical attacks targeting the nodes, hardware attacks, issues. Moreover, by statically identifying and removing un- or flashing/programming individual nodes with a malicious necessary checks for memory accesses that will never result firmware are out of scope. in memory errors, it is possible to achieve low performance overhead. 3. BACKGROUND Based on such considerations, we design nesCheck, a novel scheme that combines static analysis, type inference, and dy- 3.1 Memory Safety Vulnerabilities namic instrumentation techniques to enforce memory safety The root cause of all memory safety vulnerabilities is the on embedded systems for existing nesC programs. The goal dereferencing of invalid pointers. There are two main cat- of nesCheck is to protect embedded software against mem- egories of memory safety vulnerabilities: spatial memory ory vulnerabilities with negligible overhead and without re- safety vulnerabilities, resulting from pointers pointing to ad- quiring any source code modification. nesCheck statically dresses outside the bounds of the allocated memory area, analyzes the source code, identifies the potentially danger- and temporal memory safety vulnerabilities, resulting from ous pointer variables, automatically infers the minimum set the usage of pointers after the corresponding memory areas of dynamic runtime checks needed to enforce memory safety are deallocated (e.g. use-after-free errors). based on pointer access flow, and instruments the code ap- Our current prototype of nesCheck targets spatial mem- propriately. ory safety, but can be extended to enforce temporal safety as On one hand, solutions that enforce memory safety en- well, by lock and key mechanisms [25]. However, as mem- tirely dynamically have resource requirements that cannot ory in well-developed WSN applications is allocated stati- be satisfied on embedded platforms; on the other hand, cally instead of dynamically, temporal safety errors are not static solutions based on whole-program analysis are not ap- a pressing issue for applications that comply with the devel- plied in practice as they lead to exponential state explosion. opment guidelines for TinyOS. This includes all the applica- nesCheck is novel in tailoring its design to the challenges and tions that ship with the standard distribution of TinyOS, as constraints of the embedded world, where whole-program well as most larger-scale WSN applications. Examples of the analysis is feasible but memory and performance overhead memory vulnerabilities that nesCheck protects against are are of concern, by relying entirely on static analysis alone out-of-bounds accesses to pointers on the stack and heap, whenever possible and falling back on runtime protection uninitialized uses, and null dereferencing.