Comment by usrusr
1 month ago
What if the computer peeking and poking memory of its own Bluetooth adapter might be doing so with software running on top of the Web Bluetooth API? I sure hope that it isn't that bad, but if it was, it would still be eerily consistent with your description.
But let's ignore that web API worst case. Imagine that you have some semi-trusted software and because you don't want to take any risks, you run in nested VMs three layers deep. The software has some plausible excuse to require access to the Bluetooth (perhaps it's a beacon demo?) so you grant an exception. You're not happy with the result (the beacon demo does not work as promised?), you remove the software and you also reset all three VM layers for good measure. Gone for good, nice. Unfortunately, the guest the malware installed on the ESP when it had access is still there...
Yes, undocumented access to your own subdevices can be a really bad thing, in particular when persistence is in the picture.
>Imagine that you have some semi-trusted software and because you don't want to take any risks, you run in nested VMs three layers deep. The software has some plausible excuse to require access to the Bluetooth (perhaps it's a beacon demo?) so you grant an exception. You're not happy with the result (the beacon demo does not work as promised?), you remove the software and you also reset all three VM layers for good measure, nice. Unfortunately the guest the malware installed on the ESP when it has access is still there. Yes, undocumented access to your own subdevices can be a really bad thing, in particular when persistence is in the picture.
There are approximately 0 people who have the type of setup you described. Moreover, the chipset in question is only used in IOT devices, so it can't even be used in the way you described. Finally, does the chipset even have writeable memory? Or is it an exploit that only persists until the next reset?
Thanks. That thought "no PC uses an ESP as its wireless, ESP are used as devices that do their own wireless" was rummaging around in the back of my mind, but failed to really make itself heard.
I'm one of those who think NRF when they hear Bluetooth chip and with Nordics it's actually not that uncommon: when you want to make a PC talk ANT+ (r.i.p.) the dongle you put inside a USB port is usually the same Nrf52 you'd also find in a standalone device, only with some of its GPIO connected to the USB pads.
> But let's ignore that web API worst case. Imagine that you have some semi-trusted software and because you don't want to take any risks, you run in nested VMs three layers deep. The software has some plausible excuse to require access to the Bluetooth (perhaps it's a beacon demo?) so you grant an exception. You're not happy with the result (the beacon demo does not work as promised?), you remove the software and you also reset all three VM layers for good measure. Gone for good, nice. Unfortunately, the guest the malware installed on the ESP when it had access is still there...
You're hopping through 4 security boundaries and granting direct hardware access. If you don't understand the decisions you're making by doing that, all bets are off.
Better to give a virtualised bluetooth device and let the hypervisor drive the real one. Will hit performance a little, but it's far more secure.