Source Link Privacy.
Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices. Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls.
Update: The ESP32 “backdoor” that wasn’t.
I couldn’t find a list of devices. Anyone else find one?
The article is talking about the Espressif ESP32 micro controller (has Wi-Fi/Classic Bluetooth/BLE).
I don’t know if the variants of this chip also have the same vulnerability (my guess is yes). As someone who works on this chip, I’m interested in more discourse on this matter.
I’d also like to hear more. I have at least a dozen of these in my house.
Yeah, I caught the ESP32 part and tried to search for what devices these chips were built into, but couldn’t find one. I was curious how widespread the flaw was - as in, what consumer or infrastructure devices they might be in.
The Tasmota firmware documentation has a decent list, but it’s limited to devices that are known to be flash-able so you can install custom firmware on them. https://templates.blakadder.com/
Thanks, that’s a pretty short list - as you said it’s limited.
If it affects all ESP32s, the list is infinitely longer
The homepage just has recently added devices. Use the menu to browse by device type.
Wow. Ok, some more brand name devices are starting to be named. Still mostly consumer IOT like bulbs and smart plugs. Thanks for the update. I can see one device we own.
Oh those kind of devices. Its very popular for hobbyists and self-designed devices or cheap IoT products. Don’t know the market presence outside Asia but its quite popular in India due to its low cost.
That’s like saying “I want a list of all devices with ATmega328P.” Anyone can make a unique device with this chip as the processor, in fact I have. It’s a chip with an extremely low barrier of entry thanks to extensive documentation, lots of dev boards and libraries. Not as low as the 555 (lots of people’s first IC) but WAY lower than anything you’d traditionally consider a 32-bit CPU.
Anyway, even if you obtained the list magically, it would be of little use. To be clear: this is not an exploit. The chip just has more instructions than previously thought – instructions that you write into your program when building an ESP32 device. This can make some programs a little faster or smaller but you still need to flash them onto the microcontroller – using physical access, OTA (if you set it up in the existing FW) or some exploit (in someone’s OTA implementation, perhaps).
So your argument is what? We shouldn’t have a list because the chip is user friendly?
No. I’m saying you cannot have a complete list because the chip is user friendly. Look at all the “ESP32 project” results in the search engine of your choice if you want an incomplete list. Unlike say an Intel processor, you don’t need a contract with the manufacturer to make a device with the chip so not even Espressif has a list of commercial products that ship with their chip.
I will not stop you from building a list, I’d just not bother if I were you. There is no use of one resulting from this news. Suppose I told you “LOOK! This device’s firmware was compiled before they knew the program might be .1% more efficient with this instruction discovered in 2025!” – would that really change how you feel about the device? We live in an age of bloat; most software has way higher overhead that could be optimized away.
However, lots of people will fail to realize that, again, this is not an exploit so I’ll enjoy lower ESP32 prices for future home automation projects.
Dude, do I really need to pedantically qualify my question with “I would like a list of manufactured devices produced for sale with the chip already integrated, not hobbyist or ersatz devices in limited quantity? Nobody needs that, and a reasonable person would understand I’m not interested in what joe schmoe built in is garage.
C’mon, it’s like you’re looking for an argument. No shit we can’t have a list of every device based on your criteria, but we can reasonably expect to know what manufactured large-run devices do have it, and I think that’s a reasonable take on my question.
I agree that a list would be cool but I need to make sure that people know this is not a “WARNING! Avoid these bugged devices:” situation. Calling for a list increases unjustified panic. (Also, it looked like you didn’t understand the difficulties of listing all ESP32 products, which I was all too happy to be pedantic about.)
Am I oddly curious about the cheapest/most expensive/most popular retail ESP32 device? Yes.
Does this news increase/decrease the benefit of making such a list? No, it’s still way below the cost.
Well… Shit.
There are so, so, so, many ESP32’s in not just my house, but practically everyone I know.
There outta be fines for this BS.
You’re fine. This isn’t something that can be exploited over wifi. You literally need physical access to the device to exploit it as it’s commands over USB that allow flashing the chip.
This is a security firm making everything sound scary because they want you to buy their testing device.
You literally need physical access to the device to exploit it
You don’t need physical access. Read the article. The researcher used physical USB to discover that the Bluetooth firmware has backdoors. It doesn’t require physical access to exploit.
It’s Bluetooth that’s vulnerable.
I just re-read the article and yes, you still need physical access.
The exploit is one that bypasses OS protections to writing to the firmware. In otherwords, you need to get the device to run a malicious piece of code or exploit a vulnerability in already running code that also interacts with the bluetooth stack.
The exploit, explicitly, is not one that can be carried out with a drive-by Bluetooth connection. You also need faulty software running on the device.
“Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.”
I of course don’t know details but I’m basing my post on that sentence. “Backdoor may be possible via … rogue Bluetooth connections.”
Looking at the article, the exploit requires you to be able to send arbitrary data to the Bluetooth device over a physical connection. This means that a properly secure application will be protected from drive by connections, but if the application has an exploit that either lets an attacker write arbitrary values to the Bluetooth controller, or more likely contains a general arbitrary code execution exploit, then you could use this to rewrite values to the chip that would let you “persist” certain changes to the Bluetooth chip that would be difficult to notice.
I would consider this a moderate concern, as this will definitely increase your options if you’re looking to be able to make an attack that targets a specific device and this gives you a few additional persistence options, but any attack would have to be designed for a particular program running connected to a Bluetooth chip.
A more likely concern in my opinion would be the possibility of a supply chain attack, where someone compromises a Bluetooth chip that they know will be used to construct a particular part.
I don’t think that it’s super likely that either of these will affect the average person, only corporations and governments where espionage is an actual threat, as if you can find a Bluetooth IOT device that you want to mess with, like a Bluetooth enabled door lock, then you’re more likely to be able to find an arbitrary code execution attack which causes it to unlock immediately. Being able to spoof a different Bluetooth device isn’t likely to give you that big of an advantage when you’re working with a device that was already vulnerable for a different reason.
Thank you for the analysis, very insightful!
Do you reckon this is more of an oversight or bug in the BT stack, or a deliberately places backdoor as the title seems to suggest?
From what I can tell from looking at it, this seems like something deliberately left in, but not for malicious reasons. The op codes referenced simply give access to lower level parts of the boards programming. ESP32’s are already a user programmable board, a valid use case is to run your entire application on one if the code being run is lightweight enough to not interfere with the Bluetooth code. Either during development, or during runtime, these undocumented codes are likely used to run specific commands on the board.
The actual issue as far as I can tell, since normally it’s valid usage to rewrite the board over USB, is that ESP32 boards also offer ways to encrypt device code, and require it to be signed, and you are presumably able to mess with this in order to dump code that was expected to be securely encrypted, and overwrite code on devices that was intended to require signing. (https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/security/secure-boot-v2.html#background)
Proving what someone was thinking when they programmed something is extremely difficult unless you can find written evidence of someone specifically saying if they did something or not, but this all seems like a legitimate minor exploit in a device that wasn’t built by, or intended for, people who are working against highly resourced attackers. This is still not a concern for normal people who aren’t concerned about being attacked by spies, and if a nation state wanted to hide a vulnerability in something then there are far easier paths to take than one that only works if you can steal a microcontroller so you can connect to it over USB.
thank you for the nice analysis. this should really be voted highest.
This is about silicon. Undocumented instructions have just been found in it but they are not executable unless the ESP32’s firmware uses them. Firmware cannot be edited to use them unless you have an existing vulnerability such as physical access or insecure OTA in existing firmware (as far as researchers know).
Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.
I really wish these articles just tell us what these scenarios are. I understand companies need publicity or need to sell software but if it isn’t replicatable and the article says “might be possible” it kind of sounds like a secuity sales pitch.
This is especially the case if an attacker already has root access, planted malware, or pushed a malicious update on the device that opens up low-level access.
This part basically sounds more like a software issue where the attacker has a way in already. The system is already vulernable at this point before using the exploit found.
I don’t think there’s enough information out yet.
It is very interesting though.
In that case, how long til some open source project uses it to make a custom firmware to bypass the manufacturer bs and integrate my cheap IoTs seamlessly into Home assistant?
I think we are basically already there with ESPs :D.
You can already reflash a lot of devices for this purpose. And you could use esp-home to customise once reflashed
Really? Where can I find this
Heres the top google link i found: https://randomnerdtutorials.com/how-to-flash-a-custom-firmware-to-sonoff/
Esp-home is available as a HA addin, docs here: https://esphome.io/
Thanks
Esp-home also works with the older esp-01 - it was released as a wifi module so there are only two gpio’s, but thats enough for a lot of home automation stuff.
Here’s one i have connected to HA, where HA uses rest-api to capture some data from a game called tacticus, and it shows my available tokens for guild raid and arena
Tasmota is another option if they have your specific device in their list. Otherwise you have to do some debugging to figure out what gpio or i2c address to use.
Wrong. Read the analysis. It is a BT vulnerability. One can probably design a cheap attack system that just sends a erase flash command to any BT device in reach, instantly bricking every BT enabled ESP32 device.
Just reread it and no, it’s not a BT vulnerability. The “erase flash” command is something that has to be done by software running outside the BT stack. You can even see that inside the slides. The
UsbBluetoothsoftware is connected to the device with the flawed bluetooth chipset.The vulnerability is that if you have this chipset and compromised software, someone can flash the chipset with compromised flash. They even say that it’s not an easy attack to pull off in the article.
In general, though, physical access to the device’s USB or UART interface would be far riskier and a more realistic attack scenario.
In otherwords, the attack is something that can only be pulled off if there’s also a security vulnerability within other parts of the hardware stack.
Yeah, that’s not the main concern.
I do have a few outside. Probably not the best security-wise. Haha. Those are the first to get patched when one comes out.
Security wise, unless you are being specifically targeted by someone, you are almost certainly fine. And if you are being specifically targeted, I think someone hacking your ESPs is the least of your worries. A malicious attacker that knows your physical location can do a lot more scary things than just spying through ESPs.
Just wait until a jester creates a software that sends an erase flash backdoor command to any BT device it sees.
And runs with an USB cable flashing other peoples ESPs to ruin everyone’s day
One of my friends is a type I diabetic. He had some sort of smart thingamajig in his teenage years for measuring blood sugar, so you could monitor it over time or warn your family if you’re in some critical situation.
The jester may mean simply to prank, but they may well have blood on their hands if they fuck up medical devices such as that one.
Babe, wake up its time for your china fear mongering news
Yeah one of my more… tech adventurous friends had the most insane series of security breaches (to out it mildly) potentially related to this and some other recent ridiculousness.
What do you mean
Not related to this at all.
Fukin dmnit! I just spent the last several months fine tuning a PCB design supporting this platform. I have , what i believe to be my last iteration, being sent to fab now. I have to look i to this. My solution isnt using bluetooth, so i dont know if im vulnerable.
Go for it. It’s a bullshit attention grab. No backdoor, just some undocumented vendor commands (which is the norm for virtually every chip out there).
The exploit requires physical access. It’s not exploitable in 99% of cases
Its not a backdoor, you’re most likely fine.
The other day someone posted in Canada community that Canada should stop using Tesla cars and import Chinese cars. I replied saying, “That’s like replacing one evil with another.” I was downvoted by a lot of people. I should’ve expected it cuz a lot of people have short term memory.
“China bad” because western media says so. Please disregard the billions of dollars spent by western governments to ensure you keep thinking that way.
It’s just another capitalistic country no better or worse than Canada or the USA. Though, the Chinese government has said their intention is to move towards socialism, so good for them. I’m stuck over here witnessing fascist billionaires loot the government/working class.
Well, no, China is bad because freedom is very restricted there and because they have ambitions to dominate the world.
Yes, every other world power in the world is more or less the same. People cannot, in general, be trusted to be “good” when given the opportunity to abuse. A world power can be held in check by the presence and efforts of other world powers, though.
China is bad, because they too are a colonialism and imperialistic nation.
Just like the US and Russia.
Living conditions there continue to improve, while ours decline. A whole lot of boogie man bullshit. This article is intentionally fear mongering.
The CCP isn’t putting in a back door requiring on-site access in your litter box.
Thats super interesting! Write a poem about three gorges dam please
No, ‘China bad’ because many many examples of China bad. Such as the topic of this post.
The whole “you can’t criticize China because you’re from a country that also does bad things” is logically worthless. It’s the appeal to hypocrisy fallacy.
Not sure if you realize this but China is also ruled by a kleptocratic billionaire class that loots the working class even moreso than the US, so i’m not sure why you look up to them - China has more billionaires and a much larger wealth divide than the US. Actions speak louder than words and while Xi and the CCP often talk about cracking down on thier ultra-wealthy, they don’t really do much - couple billionaires might disappear occasionally though if they don’t praise the party line publically. One thing is for sure - I don’t see any elite CCP party members that are not also very wealthy. And it’s everyone else that’s propagandized 🤔
You really think they intentionally left a back door requiring on-site serial access?
There’s been a lot of that lately. Same here in New Zealand.
You dipshits, they’re both the bad guys now.
Because that’s not about privacy, that’s about the trade war. Retaliatory tariffs on US cars increase cost of cars for Canadians, as there are almost no car assembled in Canada. Reducing or eliminating tariffs on cars from China would lower cost of new cars for Canadians while keeping the tariffs up.
For privacy and security, not a single new car on the market is decent right now. That should be regulated, but that’s no concern for any politician at the moment.
CCP has backdoor into every tech that comes out of China. It’s not about just privacy. They control democracies based on shaping narratives. They’ll utilize everything that democracy offers and use it against countries. They don’t have freedom of speech or press so they themselves are not victims of it. EVs are really just computers on the road. Flooding the market with Chinese EVs would just mean creating a massive free network on a foreign soil for them.
All cars are computers on the road at this point, not just EVs…
While technically true, that’s not what I meant. For example, Tesla Model 3 has AMD Ryzen chip. It is a full fledged computer CPU. Although my Toyota surely has a computer onboard, it’s nowhere close to this level of tech in the Tesla. EVs from China are at the same or higher level tech-wise compared to Teslas.
As opposed to the teslas with the back doors for the us government… but will be moot when Canada is part of the states anyway
Summary: China is not a friend country. It’s a hostile country. Yes, we know.
But the news is… so is the USA to Canada now. A hostile country threatening to annex Canada and trying to cripple the economy as a way to achieve the goal. So either we slap 100% tariffs on US made cars, which would hurt Canadians, or we apply the same tariffs on Chinese cars, so reduce them from where they are at the moment.
All I meant was flooding the market with Chinese cars isn’t a huge security threat to the country. There’s another alternative. European cars.
Europe and its 50 car makers could also be considered instead of China…
Yes, but Canada had implemented 100% tariff on cars from China, following the US. That’s pre-trade war. The proposal is to lift that one.
Ah, I see. Thanks!
deleted by creator
Jesus. Okay. So when you say, “being short sighted”, you don’t literally mean the geometry of their eyes is myopic. You mean it figuratively. Exactly like the person you are correcting clearly means it figuratively when they say “short-term memory”.
A lot of people are dumb. Or maybe because they feel offended because they are Chinese, but the reality is that every Chinese company is ultimately controlled by the CCP. If I was fighting a cold war, I would do the same. Sell compromised devices to my trade partners (AKA enemies) so I have leverage when I need it.
the reality is that every Chinese company is ultimately controlled by the CCP.
Yes.
But in the same way that every US company is ultimately controlled by the US Government. And every EU company by them. And every other country by their own government.
Or maybe because they feel offended because they are Chinese
I’m Chinese-American and I’m not offended. The tankies from .ml are
People act like traditional car manufacturers don’t exist anymore even though they all offer EV options…
Is this some hardware flaw, or just something in their standard BT stack?
I was wondering the same thing. Wasn’t clear on whether these backdoors are there on purpose or because of mistakes
removed by mod
Where in the article did it say that? Did you read the article?
Yes I indeed did read the article. It’s in the section regarding the sarcasm-ESP API
Weird that they removed the reference to ESP32, one of the most common and widely known microcontrollers, from the headline.
It’s because the security company basically lied about this being a vulnerability, and probably opened themselves up to a lawsuit.
This sounds like there are some undocumented opcodes on the HCI side – the Host Computer Interface – not the wireless side. By itself, it’s not that big a deal. If someone can prove that there’s some sort of custom BLE packet that gives access to those HCI opcodes wirelessly, I’d be REALLY concerned.
But if it’s just on the host side, you can only get to it if you’ve cracked the box and have access to the wiring. If someone has that kind of access, they’re likely to be able to flash their own firmware and take over the whole device anyway.
Not sure this disclosure increases the risk any. I wouldn’t start panicking.
So explained to me, a tech illiterate in comparison, this is China bad scaremongering?
‘Backdoor’ sounds malicious with intent.The article is a security company trying to hype their company with a theoretical attack that currently has no hypothetical way to be abused
The article has an update now fixing the wording to “hidden feature” but, spoilers, every BT device has vendor specific commands.
The documentation of the part just wasn’t complete and this companies “fuzzing” tool found some vendor commands that weren’t in the data sheet
The China part just came from OP
thank you
The article is a security company
trying to hype their companyruining their reputation in an incredibly ill-thought out attack that companies will ABSOLUTELY remember.Even worse, it just makes this security company look incompetent. Like a home security company that announces a huge vulnerability in Schlage locks- there’s a key that can unlock the lock included with every lock sold!!11!!!11!one!
I agree, but unfortunately, this has become common since Heartbleed, and they seem to be able to sell their snake oil to CTOs…
Pull up a chair and pour yourself a stiff beverage…
TLDR: Don’t Panic.
If you have a regular old processor (MCU) and want to give it wireless capability, you can buy a wireless chip and stick it next to the processor, then have the MCU talk to it through a wired connection (typically UART or SPI). Think of it as the old ATDT commands that had your PC control your old screeching modems.
To standardize this communication protocol, folks came up with the Host Controller Interface (HCI) so you didn’t have to reinvent that protocol for every new chip. This was handy for people on the MCU side, since they could write firmware that worked with any wireless chip out there, and could swap out for a cheaper/faster one with minimal change.
Fast forward to the era of integrated MCU+wireless, where you had a little ARM or other lightweight processor plus a little radio, and the processor could run programs in a high-level API that abstracted out the low level wireless stuff. Plus, you could use the same radio for multiple wireless protocols, like BLE, wifi, ANT, etc. Nordic and TI were early adopters of this method.
Typically, it was the vendor’s own processor talking to their own wireless module, but they still implemented the full HCI interface and let it be accessed externally. Why? So if your design needed an extra beefy processor and used the MCU+wireless chip as a simple communication module, this would still work. The teeny MCU could be used to run something extra in parallel, or it could just sit idle. A typical example could be a laptop or cell phone. The little MCU is too small for everything else, so you pair it with a big chip and the big chip drives the little chip through HCI.
Sure, it would be cheaper if you just went with a basic ‘dumb’ wireless chip, as folks from CSR, Broadcom, and Dialog kept pointing out. But the market demanded integrated chips so we could have $10 activity trackers, fancy overpriced lightbulbs, and Twerking Santas (https://www.amazon.com/twerking-santa-claus/s?k=twerking+santa+claus).
For integrated MCU+wireless chips, most vendors didn’t release the super low-level firmware that ran between them. There was no need. It was internal plumbing. They exposed SDKs so you could control the wireless chip, or high-level Bluetooth/wifi APIs so you could connect and talk to the outside world in a few lines of code. These SDKs were unique to each vendor (like Nordic’s nRF Connect library, or TI’s SimpleLink SDK).
Then along came Espressif out of Shanghai, China with a combo chip (ESP8266) that offered processor + wifi and was so cheap and easy to program that it took the hobbyist market by storm. Oh, god… so many LED light strips, perfect for Christmas and blinky EDM lightup outfits (hello, Adafruit: https://www.adafruit.com/category/65).
Fast forward and Espressif drops the ESP32. A bigger, faster Tensilica Xtensa processor, with built-in flash storage, plus wifi, Bluetooth, and BLE in one place. Plus lots of peripherals, busses, and IO pins. Also, running FreeRTOS and eventually Arduino SDKs, and MicroPython. All for less than $5! It took off like a rocket. So many products. Plus, you could run them as little webservers. Who doesn’l love a little webserver in their pocket?
It’s gone through a few variations, including swapping out the Tensilica with an open-source RISC-V MCU, but otherwise it’s a massive seller and the gateway drug for most IoT/Smarthome nerds.
So along come these Tarlogic researchers, looking to build a direct USB to bluetooth library. This way, you can drive the wireless from, say Linux, directly. There are already BLE to USB stacks, but this one is giving access at the HCI level, in a C library. Handy if you’re doing research or developing drivers, but not the sort of thing your typical DIY person needs.
As part of their process, the researchers decide to dump the really low level ESP32 firmware and reverse engineer it.
A typical HCI implementation is a giant event loop that handles HCI opcodes and parameters. Host wants to talk to the outside world, it sets up some registers, configures the unique MAC address, then opens a channel and starts sending/receiving (hopefully without the modem screeching tones). There are typical packet encoders and decoders, multiple ISO/TCP layers, and the sort of thing that most people assume somebody else has gotten right.
For fancier implementations, there may be interrupt or DMA support. Sometimes, there’s a multi-tasking part under the hood so they can time-slice between wifi, bluetooth, and ble (aka Fusion or Coexistence support). Not that you should care. The internals of this stuff is usually nobody’s business and the vendors just include a binary blob as part of their SDK that handles things. The host systems just talk HCI. The wireless side talks HCI on the wired side, and wireless on the radio side. Everyone’s happy.
In the process of reverse engineering the low-level HCI blob, these researchers found a few extra undocumented HCI opcodes. They’re not sure what they’re for, but according to their presentation (https://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/) if my super rusty Spanish holds up, it has to do with setting MAC addresses and handling low-level Link-Level Control Protocol communications (https://www.ellisys.com/technology/een_bt10.pdf).
Now in an of itself, this is no big deal. ESP32s already let you easily set your own temporary MAC address (https://randomnerdtutorials.com/get-change-esp32-esp8266-mac-address-arduino/), so there has to be a way to override the manufacturer one. And LLCP management is a totally geeky low-level thing that the MCU needs when handling wireless packets. There are perfectly good reasons why the opcodes would be there and why Espressif may not have documented them (for example, they could be used only during manufacturing QA).
So the original presentation is a teeny bit of an exaggeration. Yes, the opcodes exists. But are they nefarious? Should we stick all our ESP32s inside Faraday cages? Is this a secret plan for the CCP to remotely control our lights and plunge the world into chaos?
As I said before, ONLY if there’s a secret as-yet-undiscovered wireless handshake that gives remote wireless access to these (or really, pretty much any other published HCI opcode). That presentation most definitely doesn’t claim that.
To see if there is a REAL backdoor, you should wait for an analysis from fine professional wireless debugging vendors like Ellisys (starting models run $30K and up), Frontline, or Spanalytics.
Incidentally, Tarlogic, the group that put out that paper have their own BLE analyzer product (https://www.tarlogic.com/es/productos/analizador-bluetooth-le/). They look to know their stuff, so they should know better than putting out clickbait-y hair-on-fire reports. But come on, who can resist a good CCP/backdoor headline? Will media run with this and blow it out of proportion? No way!
If you’ve read this far, you must safely be on your third drink or the edible’s just kicked in. Stop panicking, and wait until the pro sniffer and Bluetooth forum people give their opinions.
If it turns out there is an actual WIRELESS backdoor, then by all means, feel free to panic and toss out all your Smarthome plugs. Go ahead and revert to getting up and flicking on your light switch like a peasant. Have a sad, twerk-free Christmas.
But over a few undocumented HCI opcodes? Have another drink and relax.
Happy Sunday.
PS: controversy already up on wikipedia: https://en.m.wikipedia.org/wiki/ESP32
PPS: you may want to stock up on ESP32s for your light-up Christmas light project. Don’t be surprised if Espressif gets smacked with some hard tariffs or an outright ban, based on these ragebait headlines 🤷🏻♂️
Edit: DarkMentor offers a little more detail on the nature of the opcodes: https://darkmentor.com/blog/esp32_non-backdoor/
what a fantastic write up. thank you so much for taking the time <3
This is a very good comment. I’d give you Lemmy Gold if such a thing existed. Thanks for posting it!
At this point I welcome them to come through.
Come through with what though?
Idk what they can do with my data from my many Bluetooth devices so they are welcome to come through my Bluetooth devices 😂 and I’d be fine with being a Chinese citizen if that’s where this leads, they have healthcare and social housing.
The Chinese adding back doors into their software/hardware.
Say it ain’t so!
Say it ain’t so
Your bug is a heartbleeder
Say it ain’t so
My NIC is a bytetakerIt ain’t so.
To use the “backdoor” an attacker needs to have full access to the esp32 powered device already.
It’s like claiming that being able to leave your desk without locking your PC is a backdoor in your OS.
Yes, this is about undocumented instructions found in the silicon but they are not executable unless the ESP32’s firmware uses them. Firmware cannot be edited to use them unless you have an existing vulnerability such as physical access or insecure OTA in existing firmware (as far as researchers know).
It is good to question the “backdoor” allegations - maybe the instructions’ microcode was buggy and they didn’t want to release it.
tech backdoors are only okay when us good guys require em
Where did anyone say anything remotely like that?
I think it’s sarcasm mate.
I wouldnt be so sure about that. I’ve heard people say stuff that was mindbogglingly dumber than that, completely seriously.
it was in fact sarcasm
thats what /s is for.
How about all tech backdoors are bad and we should aim to use and make software and hardware that is ethically produced and usable without selling out your privacy and security?
China ain’t our friend but neither is our own regime, I don’t get the normies only caring about privacy and security when chinaman do the thing
Then they tuck their dicks because they got nothing to hide when domestic spook is doing the same
pathetic and intellectually disingenuous
Like a PRISM for China, is every powerful country just backdooring each other?
Thats hot.
So, what is the probability of it affecting a lot of people?
The blob strikes again
Not the first time a backdoor was found on Chinese made hardware and it won‘t be the last time. Decoupling can‘t happen quickly enough.
True, but the ESP32 is used by a lot of devices. This backdoor is pretty huge in scope of devices impacted.
It depends on what the method of attack is. I’m not seeing anything saying that it would be possible to exploit wirelessly, so this could easily be mostly a non-issue.
I mean, most users here are browsing using a device with an AMD or Intel CPU, both with known backdoors. Not the first time a backdoor was found on American made hardware and it won’t be the last.
Which government’s backdoors would you prefer?
“We know you have a choice in oppressive governments, so we appreciate you choosing ours.”
None of them, that’s why the only things in my house that connect to the internet are my computers, game consoles, and cell phone
Assuming you’re not joking here, if your computers are any way modern they almost certainly have a backdoor.
I don’t think Lemmy shitposters are getting them premium zero days used on them.
This isn’t some crazy zero day, it’s pretty well known. Intel management engine and AMD secure technology.
Obviously, but I trust my Linux mint laptop a hell of a lot better than my aunt’s XIPPLG branded wifi cat feeder that she bought off Amazon
You probably shouldn’t, check out Intel management engine and AMD secure technology.
From what I understand, the only way to mitigate the risks relating to IME or AMD PSP is to simply not have a computer in the first place. Like I’ve said elsewhere twice now, it’s worth mitigating some risks even if we can’t mitigate all of them. I don’t want the most advanced computing device in my home to be an astrolabe.
I guarantee all off those have components from manufacturers that a government could pressure for a backdoor.
You are correct, and it doesn’t change my stance at all. It’s still worth it to mitigate risk even if you can’t mitigate all risk.
Like, the fact that my 3d printer is already a fire hazard does not justify leaving a bunch of candles unattended
Not sure if joking or naive…
Like I said 6 hours ago, just because I can’t mitigate all of the risk doesn’t mean that I shouldn’t mitigate as much as I reasonably can.
My 3d printer is a fire hazard, but that’s no excuse for leaving a bunch of candles unattended.
Ah I missed the other comment, my client still had a cached view apparently. And definitely true regarding mitigation, your phrasing just read funny to me :)
One more reason to have actual open-source drivers instead of binary blobs…
