c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
Community Rules
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected]
Notable mention to [email protected]
So i think 29 undocumented commands are far too many for a mistake..
Maybe, maybe not. Keep in mind that opcodes are the lowest-level part of the programming stack. They're literally just integers transmitted on the system bus. So if you've got, for example, 35 operations that you're actually trying to implement, you need 2^n^ ≥ 35 or n = 6 signal lines in your bus to transmit it. But since 2^6^ = 64, that means it's possible to put another 29 values on that 6-bit bus, with completely undefined behavior unless you go out of your way to handle them in the instruction decoder (increasing the size and therefore cost of your silicon, which is very undesirable in an embedded chip that sells for less than $1).
It is not at all implausible for one of those undefined instructions to just happen to do something that an attacker would find useful, by sheer coincidence.
Couldn't they just designate them as no-op codes?
Yes, but to do that they have to be decoded and handled. That's basically what the commenter above was saying.
The original 6502 had many undocumented opcodes for this reason, and developers stated exploiting them for various reasons. The CMOS 65C02 redefined them to no-op. This has been going on a long time.
Probably why Android and apps are constantly asking me to turn on Bluetooth when I dont want or need it.
Not that this chip is in my phone, but it begins to seem like a pattern.
Maybe bouncer is something for you
Looks like bouncer is no longer available.
https://play.google.com/store/apps/details?id=com.samruston.permission
I do have Graphene which can do something similar. or maybe its an Android 15 feature?
Per app, there is a toggle to revoke an app's permission after an unspecified(?) period of time.
"Manage app if unused"
You lucky nexus owner. I wish GrapheneOS could be flashed on more smartphones. Yeah so that definitely reads like the feature that bouncer provides and if that's anchored at the system level the Graphene solution is guaranteed to be better too. Either way, it offers a lot of good functions that you can't simply make available on another Android via root.
Edit: I also forgot that Bouncer needs root to be fully functional.
i gather that's why they're referring to the discovery as a 'backdoor'
This is really bad as most cheap IOT devices using this chip will not receive an update all.
Would like to see a smartphone app testing this out via bluetooth so we could do some damage control at least and take them offline.
The 'S' in IOT stands for Secure
Am I misunderstanding the article? It seemed to imply remote intrusion required either Bluetooth proximity, or physical USB access.
Correct, but as bluetooth is possible over a certain range, "drive by attacks" might be possible.
The "attack" is from the host side, any remote attack is theoretical and would depend on exploiting the software on the host first to then gain access to the BT chip.
How could this have happened???
Tarlogic developed a new C-based USB Bluetooth driver that is hardware-independent and cross-platform, allowing direct access to the hardware without relying on OS-specific APIs.
Armed with this new tool, which enables raw access to Bluetooth traffic, Targolic discovered hidden vendor-specific commands (Opcode 0x3F) in the ESP32 Bluetooth firmware that allow low-level control over Bluetooth functions.
Badass.
Well that's not good.
I am conflicted on the one hand its a great thing we know about the exploit. The problem is, now everyone knows about it, seems like they've documented exactly how to do it for anyone who didn't already know how...
That’s how it goes with all security vulnerabilities. IMHO sunlight is the best disinfectant for stuff like this. But yeah, it can cause some chaos.
Better to have it out in the open then being used by sneaky nefarious types without anyone else knowing imo
In comparison to the 20 documented ones
What devices use this chip? Has it been enumerated anywhere?
A lot of devices are based around the ESP8266 / ESP32 Here is a site with a very likely VERY incomplete list
In addition to what others have said, ESP32 is often used by hobbyists, like a more powerful Arduino. These devices are extremely versatile and cheap. I have several of these in my home automation and this is very bad news :(
There's a billion, gonna be a long list.. I'd do some research on your devices and see if any of them use the esp32
I'm still looking into this but, "backdoor" appears to be incorrect and sensationalist. A team used proprietary software to uncover undocumented opcodes related to the Host Controller Interface (HCI). This could provide a path for arbitrary code execution, if one already has control of the Host... In which case they can arbitrarily execute whatever code they want.