5 ms·

This backdoor only appears on decades-old VIA C3 embedded x86 processors

by joss82 2mo ago

littlecranky67 2mo ago
They should have mentioned that in the first line of the github readme, not burried deep down in the text.
- RamRodification 2mo ago
  Buried? Deep down? The fourth paragraph, clearly labeled "Affected Systems", a minute or two into the read.
  - deleted 2mo ago
    [deleted]
  - rbanffy 2mo ago
    We have shorter attention spans now.
    - bunbun69 2mo ago
      Multiple things can be true at the same time. While we do have shorter attention spans, some (lots of?) developers absolutely suck at writing articles
      - rbanffy 2mo ago
        I fancy myself as a decent writer, but I suck at writing documentation. People describe reading my notes frustrating and incomprehensible. I find it much better to use AI to untangle my, admittedly, convoluted reasoning
      - account42 2mo ago
        And some intentionally write clickbait headlines even though the have the skills to do better.
  - fph 2mo ago
    Opening with the title "hardware backdoors in x86 CPUs" is quite misleading, though.
  - netsharc 2mo ago
    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...
  - arcfour 2mo ago
    They knew what they were doing by not including "VIA C3 CPUs" before the fourth paragraph. Come on. It should have been in the title.
__atx__ 2mo ago
Also worth noting that the exploit was published nearly decade ago. Still, even at that time, those VIA CPUs were over 15 years old.
userbinator 2mo ago
It's not even a "backdoor", it's documented in the datasheet... http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (page 82) ...which along with the already publicly-known microarchitecture of the C3 makes this statement sound like total nonsense: The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU I remember laughing at this with a few others knowledgeable in x86 when it first came out; a self-proclaimed "security researcher" who somehow failed to RTFM. There's even a Wikipedia article about it now, with a link to the alternate instruction set documentation: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set
- cinntaile 2mo ago
  It's not as clear cut as you describe it here. In the other old thread you linked there was no real consensus if this should be considered a backdoor or not.
- inigyou 2mo ago
  Was this documentation public at the time? The pdf still does not document the instructions themselves.
  - userbinator 2mo ago
    It was public at least 4 years before he first announced his discovery: https://web.archive.org/web/20140130160743/http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf https://web.archive.org/web/20140130160743/http://datasheets...
  - 23455646gg3g 2mo ago
    yes, AIS was known sandsifter was lots of noisy PR, but no new encoding findings
    - jcranmer 2mo ago
      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.
K0balt 2mo ago
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.
- hnuser123456 2mo ago
  I recently got an air purifier. The touch button controls for adjusting the fan speed didn't seem to be working, so I emailed support. They had me download their app, link the air purifier, and give them its MAC address. Then they asked me to try pressing each of the buttons a few times and email them back. I did so, and they responded that they re-calibrated the buttons using my touch samples. It worked.
  - gavinsyancey 2mo ago
evanjrowley 2mo ago
Perfect. The next the the bank's ATM "cannot process the transaction" we now have a pathway to debug the issue.
GeekyBear 2mo ago
> This backdoor only appears on decades-old VIA C3 embedded x86 processors Modern Intel and AMD chips also have separate CPU cores that neither the user nor the installed OS control. Intel Management Engine: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine AMD Platform Security Processor: https://www.wikipedia.org/wiki/AMD_Platform_Security_Processor https://www.wikipedia.org/wiki/AMD_Platform_Security_Process... Intel added them in 2008. AMD followed suit about five years later.

This backdoor only appears on decades-old VIA C3 embedded x86 processors

by joss82 2mo ago

This backdoor only appears on decades-old VIA C3 embedded x86 processors

littlecranky67 2mo ago

They should have mentioned that in the first line of the github readme, not burried deep down in the text.

RamRodification 2mo ago
Buried? Deep down? The fourth paragraph, clearly labeled "Affected Systems", a minute or two into the read.
- deleted 2mo ago
  [deleted]
- rbanffy 2mo ago
  We have shorter attention spans now.
  - bunbun69 2mo ago
    Multiple things can be true at the same time. While we do have shorter attention spans, some (lots of?) developers absolutely suck at writing articles
    - rbanffy 2mo ago
      I fancy myself as a decent writer, but I suck at writing documentation. People describe reading my notes frustrating and incomprehensible. I find it much better to use AI to untangle my, admittedly, convoluted reasoning
    - account42 2mo ago
      And some intentionally write clickbait headlines even though the have the skills to do better.
- fph 2mo ago
  Opening with the title "hardware backdoors in x86 CPUs" is quite misleading, though.
- netsharc 2mo ago
  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...
- arcfour 2mo ago
  They knew what they were doing by not including "VIA C3 CPUs" before the fourth paragraph. Come on. It should have been in the title.

__atx__ 2mo ago

Also worth noting that the exploit was published nearly decade ago. Still, even at that time, those VIA CPUs were over 15 years old.

userbinator 2mo ago

It's not even a "backdoor", it's documented in the datasheet... http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (page 82) ...which along with the already publicly-known microarchitecture of the C3 makes this statement sound like total nonsense: The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU I remember laughing at this with a few others knowledgeable in x86 when it first came out; a self-proclaimed "security researcher" who somehow failed to RTFM. There's even a Wikipedia article about it now, with a link to the alternate instruction set documentation: https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set

cinntaile 2mo ago
It's not as clear cut as you describe it here. In the other old thread you linked there was no real consensus if this should be considered a backdoor or not.
inigyou 2mo ago
Was this documentation public at the time? The pdf still does not document the instructions themselves.
- userbinator 2mo ago
  It was public at least 4 years before he first announced his discovery: https://web.archive.org/web/20140130160743/http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf https://web.archive.org/web/20140130160743/http://datasheets...
- 23455646gg3g 2mo ago
  yes, AIS was known sandsifter was lots of noisy PR, but no new encoding findings
  - jcranmer 2mo ago
    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.

K0balt 2mo ago

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.

hnuser123456 2mo ago
I recently got an air purifier. The touch button controls for adjusting the fan speed didn't seem to be working, so I emailed support. They had me download their app, link the air purifier, and give them its MAC address. Then they asked me to try pressing each of the buttons a few times and email them back. I did so, and they responded that they re-calibrated the buttons using my touch samples. It worked.
- gavinsyancey 2mo ago

evanjrowley 2mo ago

Perfect. The next the the bank's ATM "cannot process the transaction" we now have a pathway to debug the issue.

GeekyBear 2mo ago

> This backdoor only appears on decades-old VIA C3 embedded x86 processors Modern Intel and AMD chips also have separate CPU cores that neither the user nor the installed OS control. Intel Management Engine: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine AMD Platform Security Processor: https://www.wikipedia.org/wiki/AMD_Platform_Security_Processor https://www.wikipedia.org/wiki/AMD_Platform_Security_Process... Intel added them in 2008. AMD followed suit about five years later.