Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • While the README calls it a separate core, it's more likely to be a direct encoding of uops.
  • (2018)

    And "x86" sort of gives the wrong impression -- this isn't an AMD or Intel chip; it's a 2001-era VIA chip.

    by loeg
  • Intel chips also have a hardware backdoor in the form of a separate core that the neither the user nor the installed operating system control.

    Intel Management Engine:

    https://www.wikipedia.org/wiki/Intel_Management_Engine

    As do AMD chips:

    AMD Platform Security Processor:

    https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...

  • Title should be: ..in VIA C3 processors.
  • Should add (2018) to the title
    by sph
  • My bad, but I don't see an edit option anymore.
  • Misleading, clickbait title. Technically accurate, but it would be accurate if it were 3 total cpu's rather than thousands or millions so that is a low bar.

    Via C3 CPUs are the only ones affected. A security problem sure, but a relatively obscure one that doesn't effect anyone's laptop, server in the cloud, etc.

    A reasonable title is "Backdoor found in Via C3 cpus".

  • So is it apparent that this backdoor was intentionally added by VIA for nefarious purposes? Or is there any other reasonable explanation for its existence?
  • I was wondering the same, this is an ancient CPU by now, having been introduced in 2001. During development and at the introduction, most people were still running Windows 95/98/ME, which had more serious security issues (like every user essentially being admin). It may just have been a handy (debugging?) feature?
  • Yes there is a harmless explanation. The VIA C3 is a fairly simple CPU design that cracks x86 instructions into an internal simpler instruction format. Some complex x86 behaviour is normally implemented by lengthy microcode or complex state machines. VIA wanted to make their CPU simpler than Intel and AMD. To do that they exposed this internal instruction set to the BIOS to let it handle hardware initialisation and documented how to lock this feature safely away afterward. Some BIOS authors didn't read/understand the full specification. shrug.

    IIRC there are also a few hints they at least considered exposing this alternative instruction set at runtime to get more performance out of the CPU core e.g. more useable registers, more three operand instructions, saturating and packed math for DSP workloads, etc.

  • For Intel-ME and AMD PSP, you fundamentally can't see the backdoor they could produce unless you probe the seperate chip lol.
  • Or we use AI to find bug in those systems. Along with the way to completely disable those.
  • Even before that, wasn't SMM the OG x86 backdoor?
  • You can find recorded presentations on YouTube: https://youtu.be/_eSAF_qT_FY
  • As noted by userbinator: https://news.ycombinator.com/item?id=49220030

    Not a backdoor, but a documented CPU feature.

    The whitepaper about rosenbridge cannot be published because it would constitute scientific fraud.

  • Calling it a "backdoor" is subjective, because it looks enough like an unintentional exploitable bug that one could make that argument. Is an accidental backdoor still a backdoor? That's pure semantics.
  • > Not a backdoor, but a documented CPU feature.

    I would be even more explicit and call it “Not a backdoor, but a documented feature of ancient de facto unused Via C3 CPU.”

  • This shows that large companies making closed-source CPUs cannot be trusted. No doubt they would add whatever the government asks them to add.

    What can be done to mitigate this? One option would be to buy a large FPGA and flash it with an open-source CPU. Another would be to emulate a CPU, working with encrypted data and commands, so that even if the backdoor in a host CPU tries to overwrite memory, it would only crash the emulated OS. One more option would be to run the code in a Virtual Machine like QEMU which translates the code and prevents issuing unknown instructions.

  • Once you control the hosts CPU it's game over for the guest. The best you can do is to fetch old PPC G4 Apple computers or Thinkpads.
  • Another thing that can be done is more crowdfunded bounty programs.

    5 here: https://cybersecuritynews.com/bug-bounty-platforms/

    The issue are "bugs" could be randomly distributed, even across the same version number of some device.

    Sample sizes and statistics come into play at that point.

    Whistleblower protections are an avenue, but people can still be dealt with harshly (Schulte) and degree-of-protection can come down to motive. But motive itself is multivariate, is it not? A local-first Fediverse, with some type of "guaranteed anonymity" would work, though. But anonymity doesn't mean something can't be a hoax either, so it becomes a signal vs noise issue at that point. Yet, "nothing totally secure ever really is."

    Source information can be embedded in the period of a printed sentence too.

    A moral world is the answer to many problems. Something to ponder. People are said to only see the errors in their ways after death in the "hall of mirrors."

    -- https://web.archive.org/web/20060102095331/http://maitreya-e...

    Economic espionage is something to also think about. You may be doing everything right and that's what makes you a target. "If I'm not top dog, target anyone that is."

    Perfect anonymity in crypto can also aid whistleblowing so that dump data = get paid.

  • It's not just the government. The government sneakily adds stuff they think only they can exploit, but skilled non-state actors can exploit hardware features regardless of whether it was put there by the government. And as we get widespread diffusion of increasingly capable AI, it will become easy and cheap to do for pretty much anyone, and so will defense.

    Assuming bio-digital integration continues (i.e., humans keep pace with ASI via neural interfaces), the long term solution is total hardware sovereignty, aka the digital equivalent of bodily integrity and autonomy. We have to miniaturize and widely diffuse fab technology such that computer manufacturing can be done in local small businesses or even at home: automated chip fabbing, 3D printing, and assembly in one fridge-sized appliance you can buy at the nearest supermarket, and it can make parts to build another one of itself.

    It's basically reproduction, but for the digital part of your body instead of the bio part. You should be able to design and fab your own custom chips, PCB, and chassis to build your neural interface from scratch, and write personal defense software that actively adapts to threats - a digital immune system. You'll also have the option to delegate some or all of that to a collective, but it would mean losing your individual sovereignty and becoming part of a larger organism in a symbiogenesis or multicellular evolution kind of way.

  • >What can be done to mitigate this?

    Buy hardware used by government computers that are rivals to your country.

    So if American, buy Chinese CPUs and install Chinese Linux or HarmoneyOS Assuming there is nothing you are doing of interest to them, as that will also have back doors

    After Snowden, one can only imagine the worst and think everything has a backdoor.

    But unless you are a high level terrorist or other person of interest, no state organization is going to target you at this level

    P.s. you say no one can trust closed source, but a lot of open source is maintained by one or two people or a small group, just takes infiltration by one or two trusted contributors to push malicious code in and unless someone looks and finds that code amongst millions of lines of code, may never be discovered (more so as mainstream media won't publish any thing)

    by v5v3
  • This backdoor only appears on decades-old VIA C3 embedded x86 processors
  • Perfect. The next the the bank's ATM "cannot process the transaction" we now have a pathway to debug the issue.
  • Also worth noting that the exploit was published nearly decade ago. Still, even at that time, those VIA CPUs were over 15 years old.
  • It's not even a "backdoor", it's documented in the datasheet...

    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

  • They should have mentioned that in the first line of the github readme, not burried deep down in the text.
  • > 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

    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.

  • 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.

  • this 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 to dive into.

    using his own cpu fuzzer, msr fuzzing techniques etc. he has found, reversed and implemented attacks through hardware bugs and backdoors.

    It cant be confirmed if a backdoor is malicious or for debugging but essentially the capabilities gained through them are what is important.

    These techniques he shows throughout his videos are not super tricky to replicate and I can recommend people who have interest to dive into it, reproduce things and try to help in this domain to raise awareness and findings.

    Another good avenu is: Defcon 21 - Decapping Chips The Strike Easy Hard Way

    People speak about supply chain issues in NPM and Pip etc. but these are much more severe and hard to detect.

    Almost no one looks at it. Most vendors totally ignore it because you cannot sell products against it. (if ud detect it u need to trash the hw so its not handy... for sales...)