SoylentNews is people
SoylentNews
Submitted via IRC for boru.
https://www.infoq.com/news/2020/07/nRF52-debug-resurrect/:
A recent hardware attack on the Nordic nRF52 chip uses local access to gain chip-level debugging capabilities that persist in silicon, unpatchable in software. Nordic has confirmed the issue and encouraged device manufacturers to detect openings of the enclosure, as the chip is not hardened against fault injection.
This chip is used in so many bluetooth products. Might be fun to go wardriving and find some and see if any have accessible SWD pins.
This discussion has been archived.
No new comments can be posted.
Hardware Attack Exposes nRF52 Debugger
|
Log In/Create an Account
| Top
| 29 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Ten years of rejection slips is nature's way of telling you to stop writing.
-- R. Geis
(Score: 3, Insightful) by sjames on Friday July 17 2020, @09:34PM (2 children)
That's why I take vulnerability reports with a few pounds of salt.
Background for people who don't do a lot of embedded device work:
Many devices, including the nrf52 series include a hardware debugging interface (also used for initial firmware loading at the factory). Often those are exposed on the board as small conductive test points rather than having a socket. They're visible on many devices. To access them, the board is placed in a jig with spring loaded pogo pins (contact pins with an action very much like the bottom of a pogo stick). Sometimes they are disabled after the factory firmware load to make reverse engineering harder.
Any hack involving the debugging interface is necessarily hands-on and involves opening the case. There will be no drive by hacking of devices through the debugging interface.
On the nrf52 series, the hardware debugging can be disabled by setting a register on the device. The vulnerability is that given enough tries, it is possible to use well timed power glitching to make the device fail to disable the debug interface as it powers up, allowing you to read out the firmware and data.
Other devices with debugging interfaces have fuses you can blow after factory load to disable debugging, but a sufficiently determined attacker with resources can probably de-cap the chip and read the firmware out anyway. So it's more a matter of how hard is it rather than is it possible.
(Score: 3, Insightful) by Immerman on Friday July 17 2020, @11:50PM (1 child)
Yeah, it strikes me as very bizarre that hardware controlled access to debugging and other features is considered by anyone to be a security flaw.
I mean, sure, if you're talking owner-hostile security such as keeping secret the Blueray decryption keys in a drive, debug modes are a potential weakness. Maybe too if you're talking high-security electronic locks, or medical equipment that might be tampered with to insert a literal "kill switch".
But for consumer hardware? Access to debug modes, etc. is a wonderful boon to tinkerers, and reinforces that it's *your* hardware, not just hardware you've purchased the right to use.
(Score: 2) by sjames on Saturday July 18 2020, @07:26AM
There are a few legitimate cases where the BLE device holds access tokens to the owner's devices, but I agree that locking the owner out is less than honorable.
The nrf isn't so bad about that, you can restore debugging to the device itself if you do a full chip erase (that function works even when debugging is disabled), but of course then it's on you to provide new firmware.