[dead]
Hardware backdoors in some x86 CPUs
61–70 of 102 posts
Re: Hardware backdoors in some x86 CPUs
#62This backdoor only appears on decades-old VIA C3 embedded x86 processors
TBF the specific backdoor isn’t the point of the article. It’s a cautionary tale. The point is that practically all systems above the MCU level, and even some of those, have lower level systems that are often undocumented or not intended for use by the hardware designers, much less the end users. Those systems often have extremely low level access to system resources.
For example, I am building a device that records motion data, video, audio, and lidar imaging. Inside the 6 dollar IMU and the 12 dollar lidar sensor are powerful processors that load binary blobs provided by the manufacturer. The lidar could potentially gain access to any of the system data stored on the SPI bus, which includes the bulk storage and secondary RAM for the system. It could exfiltrate that data using its laser to anyone within a few hundred meters in the laser fov. It could also receive remote c&c over its optical sensor. The only thing that prevents that from being the case is that I trust the blob does not include the code to do those things, but it would be trivial to replace the blob with one that does.
Millions of devices are made that include basic wifi functionality. often, this comes in the form of a dedicated WiFi module. Those almost entirely consist of a powerful processor running a proprietary binary blobs, connected to some internal bus of the system that may give it access to some or all of the functions of the device, or at the very least could cause the device to malfunction. These WiFi phy modules are sub$1, pervasive, and often built in to devices that do not have any advertised connectivity features. A threat actor that has knowledge of an attack surface for that opaque blob can probably cause >50% of the connected devices built with that product to malfunction, in some cases in serious and dangerous ways, and sometimes to exfiltrate data that might be compromising or valuable.
That’s what this article is really about.
Re: Hardware backdoors in some x86 CPUs
#63Earlier quoted context omitted.
They should have mentioned that in the first line of the github readme, not burried deep down in the text.
Buried? Deep down? The fourth paragraph, clearly labeled "Affected Systems", a minute or two into the read.
Imagine getting a letter "High Risk of Cancer" and getting all the way to the 4th paragraph to see it's just relevant to a race of blue aliens...
Re: Hardware backdoors in some x86 CPUs
#64Click bait title, please change it to VIA C3 CPUs
I recommend flagging this sort of crap to death...
Stupid autistic policy of "Don't editorialize the title"...
Re: Hardware backdoors in some x86 CPUs
#65Click bait title, please change it to VIA C3 CPUs
My bad, HN doesn't allow editing after an hour of posting
Re: Hardware backdoors in some x86 CPUs
#66Earlier quoted context omitted.
Sure but the cops aren't going to pull you over based on what you think about Chinese policy. Government do mess with people across international borders, but the capacity to do that is inherently limited.
Blackmail is still a possibility ... Plus your data can be sold on the market. To US based entities. While the Chinese still hold on to the data for future uses ...
That still doesn't resolve who is more likely to blackmail or otherwise misuse data. I think it's a Chinese saying: the mountains are high and the emperor is far away.
Re: Hardware backdoors in some x86 CPUs
#67Earlier quoted context omitted.
Password resets aren't "backdoors" unless they contain a flaw the defeats any security protections. It's not just that the backdoor is less secure than the front, the backdoor has no security or is so easily defeated the security may as well not exist. I'm surprised the hidden aspect of backdoor is so forward in folks minds. In my thinking nothing in cyber security is hidden, I drop the obviously present hidden part…
No offense but I don’t think you have a clear enough definition in your head and you’re making it up as we go along and you get challenged. >> I'm probably mistaken, but I've always referred to password resets as backdoors > Password resets aren't "backdoors" unless they contain a flaw the defeats any security protections. You really have to make up your mind. It was “always” but then it wasn’t, and even as you put i…
no offense taken. i shouldnt have included password resets in my def. it muddied the conversation. covert is part of a def, at least sometimes, but i think its still acurate to drop it. consider a machine with two copies of ssh running, one of 22 with authentication and another on 2222 with an automatic root login. the instance on 2222 would be considered a backdoor, even though its barely hidden. Swap the ports and it's an unauthenticated frontdoor, but i'd still call it a backdoor and expect everyone to know what i mean. the important part is its bypassing securit, not that its hidden.
Re: Hardware backdoors in some x86 CPUs
#68A much better title would be "A hardware backdoor in a historical VIA x86 CPU".
Re: Hardware backdoors in some x86 CPUs
#69Earlier quoted context omitted.
Was this documentation public at the time? The pdf still does not document the instructions themselves.
yes, AIS was known sandsifter was lots of noisy PR, but no new encoding findings
AFAIK, sandsifter did find a halt-and-catch-fire instruction on one of the CPUs, but I haven't seen anyone announce which CPU model it was.
Re: Hardware backdoors in some x86 CPUs
#70this is pretty old by now but still very relevant. people dont look at this enough but with rising chip complexities for TPU units etc. and a shift towards poorly documented hardware like NVIDIA gives this problem new fuel. Domas (and maybe his team or colleagues?) has put out shit tons of very interesting materials over the past years on advanced malware, implants and things like Cantor Dust which are amazing things…
A poorly documented or undocumented (debugging) backdoor in a chip marketed for ATMs and medical hardware, enabled by default, at the very least qualifies as reckless endangerment.