by iracigt on 3/8/25, 4:58 PM
I think the title is a bit misleading. If I'm reading correctly, the "backdoor" allows a computer to peek and poke memory and other low-level functions of
its own USB Bluetooth adapter. I don't this this is usable over the air?
Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable.
If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.
by lima on 3/8/25, 5:04 PM
The researchers found undocumented hardware functionality which allows
someone who already has code execution a greater-than-expected degree of low-level access to the ESP32 wifi stack.
Calling this a "backdoor" is just pure clickbait.
by Palomides on 3/8/25, 4:57 PM
I'm confused, is it that the bluetooth stack has a few undocumented commands? if these are only accessible to the code already running on the device, I'm not sure I would call it a backdoor
by mmastrac on 3/8/25, 5:06 PM
In theory you probably should have low-level access to your attached BT radio itself, so this is just kind of expected, isn't it?
I prefer when devices have these low-level interfaces. Perhaps the problem is the lack of documentation rather than existence?
I used to use the memory read/write commands via USB on Qualcomm radios to unlock and otherwise take ownership of otherwise locked-down devices. Given that was a full OOB read/write I'd consider that maybe not great, but if this is only accessible from flashed code all the better.
by rurban on 3/8/25, 4:45 PM
by Aurornis on 3/8/25, 5:28 PM
TL;DR: They reverse engineered the firmware and found HCI commands to do things like read/write memory, send packets, and set the MAC address.
Not really a backdoor. I don't know if they called it a backdoor (presentation is in Spanish), or if the journalists are calling it a backdoor to get more clicks.
You'd need to have arbitrary access to send HCI commands to the device to use these commands. That means you're already controlling the device and how it operates. This isn't something that gets remotely exploited over the wireless link. Any exploits would already have to have full control of the device, at which point being able to change the MAC address or send packets isn't really a surprise anyway.
Interesting research, but really groan-inducing to see it spun as a "backdoor". I don't know who's to blame for the wording, though. I'm guessing the journalists?
EDIT: For an analogy that might be more familiar, imagine if someone discovered that the Ethernet controller on a common IOT chip could change its MAC address or send arbitrary packets if the firmware told it to. This is the same thing, but with Bluetooth.
by roger_ on 3/8/25, 5:20 PM
I hate sensational stories like this. Now Espressif is gonna feel pressured to be even more closed.
by raydiak on 3/8/25, 10:56 PM
So everyone's fine installing opaque binary blob drivers which run in kernel space on their desktops and laptops and not even having root access to their own cloud-controlled phones, but some undocumented low-level ESP32 commands which require the device to already be compromised are a news-worthy threat vector.
Really wonder if something got lost in translation, here. In the past we would have just thought that was cool and looked for a way to turn it into a SDR.
by K0balt on 3/8/25, 9:40 PM
This is good research, but a bad headline. As an attack vector, this requires physical access and could already be done by other means in almost all cases. So, “undocumented commands found in common Bluetooth chip” would be a better headline.
by jimrandomh on 3/9/25, 12:20 AM
This headline is a lie. A backdoor in a Bluetooth chip would be something which enabled a wireless attacker to gain code execution on the chip. This article reports on something which allows
the device drivers of the attached device to gain code execution on the chip, which does not violate a security boundary.
(In a well-functioning journalism ecosystem, this would require a retraction and would significantly harm the reputation of the outlet that wrote it. Sadly this will not happen.)
by slater on 3/8/25, 9:22 PM
Am I misremembering, or wasn't there some hubbub ca. 2010 where someone was going to do a presentation at CCC about how Bluetooth is basically swiss cheese in terms of security, and someone got all huffy about it and it was all hush-hush'd and the presentation cancelled?
by RicoElectrico on 3/8/25, 5:00 PM
FWIW almost nobody uses ESP32 for Bluetooth alone. This is primarily a Wi-Fi SoC. "Billion devices" is a ridiculous claim if most of them don't use BT features anyway.
by ceejayoz on 3/8/25, 4:56 PM
The next world war seems like it’ll be about five minutes long. Nukes won’t be required to send us back to the Stone Age.
by ddtaylor on 3/8/25, 5:34 PM
No plausible attack described for a reason.
by Woodi on 3/9/25, 10:05 AM
Got me think: it's time to end using binaries of assembler. Just some intermediate bytecode (can be 1:1 to assembly) and private VM that, for starters instruction whitelisting.
I know - 'if' (at minimum) on every asssembly instruction :> But there is no other way then that. Life.
by Retr0id on 3/8/25, 5:01 PM
It's unclear to me what a practical vulnerability/attack scenario would look like here.
by realitysballs on 3/8/25, 4:57 PM
Is this vuln. fixable via firmware or is the vulnerability inherent in the chip architecture?
by pabs3 on 3/9/25, 12:26 AM
by russellbeattie on 3/8/25, 9:43 PM
Can any app running on an Android device with an ESP32 save code permanently to flash memory? Would an app have that level of access to send arbitrary low-level commands to the hardware?
by almosthere on 3/8/25, 5:07 PM
Anyone want to start a Faraday cage laptop case company
by millerm on 3/8/25, 4:55 PM
Funny that I just pulled out an ESP32 dev kit a couple days ago and I honestly questioned myself with "how do you even know these things are secure at all?" Glad I know the answer now.
I'm starting to miss the days of being disconnected more and more as time goes on. This constant churn of having to monitor and lockdown everything you own down is becoming a complete negative.
by noodlesUK on 3/8/25, 4:56 PM
EDIT: My Spanish isn't very good, but reading the slides it doesn't sound like the vulnerability is likely to be remotely exploitable, it sounds like it's only an issue if the chip is in HCI mode and being used as a bluetooth adapter. If someone who speaks Spanish could confirm I would be very appreciative.
by fsflover on 3/8/25, 5:16 PM
Again, the hardware kill switch in my Librem 5 looks like a necessary feature.
by nikisweeting on 3/9/25, 1:02 AM
Can we please put "ESP32" in the title somewhere, so many people are going to miss this headline because it's so generic clickbait sounding.
by IYasha on 3/9/25, 1:22 PM
So, what's next? Declare having "sudo" or "runas" a vulnerability?
Oh, wait, it's been already do... NO CARRIER
by abetancort on 3/8/25, 9:14 PM
garbage.
by asdfologist on 3/8/25, 4:51 PM