In a previous post
Raelize demonstrated that it was possible to glitch the ESP32 chip via electromagnetic fault injection. In this, they combine this known issue with the idea of altering a copy operation to set the PC register.
All of this sounds nice in theory: you control the data being copied but not the location of the data. So, you use the glitching in order to affect the address this is getting written to. But, how practical is this!? Apparently, this is legit!
During the boot operation, devices copy data from external NVRAM (flash) into volatile memory. With physical access, NVRAM can normally be altered, the value of these variables can be edited in order to control the value during the execution.
The goal of the attack is to load an arbitrary value into the PC register while is copying data. In order to control the data, they overwrite the bootloader with arbitrary data. The processor will copy the data over prior to the signature check occurring.
The bootloader is overwritten to a ROM function pointer that prints data to the serial interface multiple times. Overwriting with this data does with the continuous pointer does two things: removes the window for writing the proper data and makes it easy to observe with the glitch has succeeded.
Since the bootloader is copied at the end of the flash activity, the glitch is added during the copying process. Hopefully, when this copy occurs, the glitch will cause a different address to be written to, causing the output to appear over the serial console.
The first attempt failed when using the same glitch location on the chip as before. After this, they changed the location of the EMFI and found a place to cause the glitch.
After two more runs, they found the perfect place and timing for the glitch. They got a successful call to the serial output about 0.43% percent of the time! If this was a cryptocurrency wallet, it only takes one successful attack.
Why does this attack work? There is a copy loop that is a large wrapper around memcopy
. On the Xtensa architecture, the return address is stored within the register a0
. By corrupting an instruction, the glitch could move the ROM function address into a0.
In order to make it impossible to alter the bootloader, EspressIf recommends that customers use Flash Encrypt. This does not mitigate the vulnerability, but does make it significantly harder to exploit.