I know tech reporting has gone downhill, but I was really surprised by how badly this minor issue was overhyped.. articles with titles like "Hidden Backdoor Discovery Could Expose 1 Billion Bluetooth Devices To Hackers" coming out even yesterday. It's a stretch to even call this a back door.
The headlines I saw were irresponsible journalism, plain and simple. There ought to be some significant repercussions or at least apologies and lessons learned posts for those publications and/or authors for crying wolf.
I cant say exactly which ones, but the main problem to me is the "second hand news".
probably most news outlets didn't made any research, they just rewrote what the previous outlet published.
as in, "we don't know either, but those guys do!"
so they probably went confident that they weren't wrong with the argument that someone else did the research for them.
i wouldn't dare call them journalists, and it is rather unlikely all of them independently reached the same conclusion that this is a "massive vulnerability".
That means you could attach wires to any device and simply overwrite the firmware on them, replacing it with your own. If that's not a severe security vulnerability, I don't know!
There's proof that this isn't a backdoor. There isn't proof that there isn't a backdoor, but that's a wildly different claim then "we found a backdoor".
It it possible to create firmware that is encrypted and cannot be read out. Espressif state there is no security issues, but I have a feeling that these debug commands may be used to read out the flash of a properly secured esp32 that otherwise would not be possible…
You need arbitrary code execution on the main cpu to execute the debug commands. Once you have that, it's game over anyway. Why not just post the data to a url rather than trying to smuggle it out in Bluetooth headers? Or just broadcast it via normal Bluetooth packets?
Tarlogics blog post, it is mentioned “modifying chips arbitrarily”, “infecting chips with malicious code”, “obtain confidential information stored on them”.
Even though they rephrased the backdoor wording, the remaining statements make me believe the undocumented functions can be used to gain code execution on the main cpu.
The problem is that Tarlogic went full nuclear with "There is a Backdoor in ESP32!!" all over the tech media based on logic that aligns with yours. "They had a feeling."
This is not a backdoor. It is arguably poor security design as one might like it if the BTLE controller was a separate permissions domain. But it isn't, and doesn't have to be, and there isn't even a theoretical vulnerability demonstrated.
This is more concise and clearer. Their first one mocked them being called undocumented, putting it in quotes, when they were in fact undocumented. The main point is that if malicious software has access to these commands, it has access to the rest of the system already so this is the least of your problems (if I understand this correctly).
That's about the right response. These don't expose a command across a security boundary. You can only exercise them if you're already executing arbitary code on the main CPU core.
Honestly the original Tarlogic report was so irresponsible that I have to wonder if Espressif is considering legal action.
Why does that matter at all? There's no persistence granted by the debug commands. When you flash it with your firmware, it's clean. If you trust the firmware that ships, they can do arbitrary code in it, so why care about a few debug interfaces?
There was no such attack demonstrated. The debug commands operate on the memory of the running BTLE controller. They can't be used to modify persistent firmware.
reply