Blacklist Nordic DFU service
Closed this issue · 7 comments
00001530-1212-efde-1523-785feabcd123
The latest version, v11, of the nRF5 SDK doesn't support checking signatures of transferred firmware images. That introduces what I think is an unacceptable risk of users being phished to update their devices to malicious firmware. There's some experimental support, for manufacturers who go looking for it, but it's undocumented, and I don't expect enough to adopt it to justify the risk to everyone else.
Let's discuss here if there are any mitigations I've missed that would argue against blacklisting.
It seems unfair to penalize the Nordic DFU service when you can already do this with any other service UUID. How about adding some whitelisted URLs to https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt?
That way, we will let trustworthy websites use this DFU service while it doesn't yet support checking signatures of transferred firmware images.
Obviously, we'll remove these URLs once signatures check are enabled by default.
# This file holds a list of GATT UUIDs that websites using the Web
# Bluetooth API are forbidden from accessing.
## Services
# org.bluetooth.service.human_interface_device
# Direct access to HID devices like keyboards would let web pages
# become keyloggers.
00001812-0000-1000-8000-00805f9b34fb
+ # Nordic DFU Service
+ 00001530-1212-efde-1523-785feabcd123 https://example.comWDYT?
What Francois is suggesting seems reasonable. Note that there will probably be a new UUID for the Nordic DFU service that supports signing, to guarantee against any fallback insecurities.
@beaufortfrancois What would the process be for getting on the list of trusted firmware updaters for a given manufacturer's service? Would a malicious actor just need to release some hardware using Nordic's service in order to get access to every other device using the same service?
The centralized firmware-update services are, in general, a bigger risk than one-off UUIDs, because a hostile site could attack them all at once, rather than needing to discover the update-UUID of each device individually. The presence of the Nordic UUID also tells the attacker some things about the hardware, that they could use to write a better attack, while a custom UUID would again make them do work specifically for that UUID. That said, we should be trying to blacklist every unsigned firmware-update UUID; I'm just focusing on the big ones first.
@ketile Adding a new UUID for the signed service would be great because it won't make us debate whether a large enough fraction of users of the old service have upgraded. Is there any chance the new service can check signatures by default? So, for instance, the code won't build until you either plug in your public key or take some other action to intentionally disable security?
@jyasskin Yes, the new signed DFU service UUID will check signatures by default and there is no option to turn it off. Any unsigned DFU code will simply be discarded.
If there is indeed a new UUID for the signed DFU service, then we can/should definitely blacklist the unsecure 00001530-1212-efde-1523-785feabcd123 DFU service. It would be better than a whitelist for sure.
@jyasskin I was more thinking about whitelisting "generic" tools like Web IDEs rather than specific official device URLs for the unsecure DFU service.
The centralized firmware-update services are, in general, a bigger risk than one-off UUIDs, because a hostile site could attack them all at once, rather than needing to discover the update-UUID of each device individually. The presence of the Nordic UUID also tells the attacker some things about the hardware, that they could use to write a better attack, while a custom UUID would again make them do work specifically for that UUID.
I don't see how that's that much more difficult. All it takes is to add all "known" DFU service UUIDs to the optionalServices filters key and try all of them.
That said, we should be trying to blacklist every unsigned firmware-update UUID; I'm just focusing on the big ones first.
👍