There is a scene from the movie RED (Retired, Extremely Dangerous) where Bruce Willis encounters a highly-secure door with a constantly changing lock code deep inside the CIA. Knowing the lock would be impossible to break, he simply destroyed the wall next to the door, reached through, and opened the door from the other side. We thought about that when we saw [raelize’s] hack to bypass the ESP32’s security measures.
Before you throw out all your ESP32 spy gadgets, though, be aware that the V3 silicon can be made to prevent the attack. V1 and V2, however, have a flaw that — if you know how to exploit it — renders secure boot and flash encryption almost meaningless.
The hack centers around the UART bootloader. You can cause the chip to enter that mode and do basic operations such as read and write RAM and registers. You can also execute code from RAM. That’s not a particular security risk, though, since the flash memory may be encrypted. Decryption is transparent in the hardware and the chip doesn’t do the decryption during the boot loader mode. Sure, you can read the encrypted flash, but you could do that with some fancy desoldering or probing techniques, too.
During a normal boot, a bootloader in flash is placed in RAM. If you can glitch the CPU at just the right time — in theory — you could force the processor to run your RAM-based code in normal mode where the flash is already decrypted. The only problem is, they tried about 1,000,000 cycles and had no success. But they did notice something odd.
The illegal instruction exception that occurred during the glitch was due to an instruction in the original RAM code winding up in the PC register. This allows an attacker to load an arbitrary address in RAM into the PC if the glitch is timed just perfectly. It turns out, it is just that easy.
We wondered why a data item would wind up in the program counter and apparently [raelize] wondered the same thing. There are a few theories, but no one seems to know for sure. At least, no one who isn’t under a non-disclosure agreement.
Once you can set the PC address arbitrarily, it is easy enough to jump back into the UART bootloader. It took a little experimenting, but eventually, the unencrypted flash came pouring out of the serial port.
This is good work and we are glad the latest silicon doesn’t show the problem. The work is captured in an official advisory, so the community will know what is possible.
There have been quite a few security-related exploits lately. Usually, we think of ESP tools as part of the hacker’s toolset, not a target, but — of course — anything is fair game.
The Link LonkSeptember 24, 2020 at 03:00PM
https://ift.tt/3iZxJHf
6 thoughts on “ESP32 Vulnerability Affects Older Chips” - Hackaday
https://ift.tt/2RGyUAH
Chips
No comments:
Post a Comment