Snippet 19: Sweytooth Example Attack- Sequencial ATT Deadlock

Part of the SweynTooth family: two back-to-back Attribute Protocol requests were enough to deadlock several BLE system-on-chips whose state machines never anticipated the sequence. Worse, a patched chip does not mean a patched product.

Key Takeaways

• Two rapid ATT requests deadlocked multiple BLE system-on-chips by driving their state machines into a stuck loop
• The affected chips sit inside smart locks, wearables, and other finished products from many vendors
• Chip vendors shipped fixes, but an SoC patch rarely reaches devices already manufactured and deployed
• Fragile protocol handling makes availability attacks on BLE devices trivially cheap

Video Transcript

The Attribute Protocol, so this is where one Bluetooth Low Energy device asks about the capabilities of another Bluetooth Low Energy device. And it's supposed to be a request reply sort of sequence. They noted that if they just send two quick subsequent requests, that deadlocked a different set of SoCs. There again, their state machine didn't handle that properly, and it just caused the code to get stuck in a while loop. So a few plots from their paper. This is the table of affected vendors and models.

And this is a mapping of the vulnerability type and the name and the CVE. And they did note, this is from a couple of months ago in April, end of April, that many SoC vendors have been responsive and making fixes. A few are still pending. But it's worth noting, these are the SoCs. So this is the chip that the end manufacturer, the smart lock maker, or the smartwatch maker buys. So even if the SoC has been patched, it doesn't mean the end device has been patched.

And it's unlikely, the paper notes, for a lot of these devices, it's hard to patch an SoC after it's been implemented and in device system.