3 ms·
How you think always-open debug is NOT a security issue? The blog post is a "nothing to see here". You really fell for it? Do we still do car analogies? Here's
by 1oooqooq 2y ago
How you think always-open debug is NOT a security issue?
The blog post is a "nothing to see here". You really fell for it? Do we still do car analogies? Here's this car with just a ignition button without keys, and keys to your home in the glovebox and the address already on the GPS... but the thief would have to break into the car first!
- Draiken 2y agoJust like every single car in existence where you can get in and mess with anything inside it? This analogy makes no sense at all. Once you break into a car, you can quite literally do anything to it. The keys to your home part is simply random.
- kelnos 2y agoThere's nothing to "fall for". Do you have specific evidence that refutes Espressif's rationale for why they believe it's not a security issue. No, a flawed car analogy doesn't count. If you can break into the application running on an ESP32, you already have full access to RAM etc. The debug HCI commands will not give you any extra access. Yes, security researchers are incentivized to make issues seem like more of a problem than they are, and vendors are incentivized to minimize them. In this case, though, the reality is much closer to Espressif's version.
- 1oooqooq 2y agoI'm old school. I know those boards won't run virtualized unsafe code* but I still like to know what can fiddle with memory behind my back. * as we assumed with sbcs like raspberypi earlier...
- pipe01 2y agoNo, the analogy would be storing a key to your house in a box inside your house. You're already inside the house, you don't need the keys.