Deeply Embedded Cores are RISCy Bridgeness
September 7, 2018 2:04 AM Subscribe
GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs (slyt, 50m)
A conference talk on sleuthing out a processor vulnerability, from patent-speak to payload.
Slides are at https://www.blackhat.com/us-18/briefings/schedule/#god-mode-unlocked---hardware-backdoors-in-x86-cpus-10194 - the link in the youtube description.
posted by edd at 2:31 AM on September 7, 2018 [5 favorites]
posted by edd at 2:31 AM on September 7, 2018 [5 favorites]
On big endian processors it would be Dog Mode. Chip designers made wrong choices.
posted by srboisvert at 2:43 AM on September 7, 2018 [25 favorites]
posted by srboisvert at 2:43 AM on September 7, 2018 [25 favorites]
Yeah, forget “Reflections on Trusting Trust,” this is like finding a midget under your hat who can control your mind & body.
It’s also especially creepy to me that this is activated with a simple system call — no crazy exploit or special hardware dongle is required. How many others are there, still out there?
posted by wenestvedt at 3:13 AM on September 7, 2018
It’s also especially creepy to me that this is activated with a simple system call — no crazy exploit or special hardware dongle is required. How many others are there, still out there?
posted by wenestvedt at 3:13 AM on September 7, 2018
Security by obscurity is everywhere. Most of the time, it works. Then someone gets curious or motivated to start rooting around. Hilariously, this is what the whole escape room thing is. We're training a generation of physical plant hackers. Probably a good thing.
posted by seanmpuckett at 5:14 AM on September 7, 2018 [4 favorites]
posted by seanmpuckett at 5:14 AM on September 7, 2018 [4 favorites]
This is a really cool tale of reverse engineering. But the existence of this "feature", and how to activate it, was documented pretty well in the CPU's datasheet (page A-10). The sad thing is that no operating system (AFAIK) bothers to explicitly disable it.
posted by reynaert at 5:31 AM on September 7, 2018 [10 favorites]
posted by reynaert at 5:31 AM on September 7, 2018 [10 favorites]
This is so cool and I am completely running sandsifter on my laptop tonight.
posted by phooky at 5:40 AM on September 7, 2018
posted by phooky at 5:40 AM on September 7, 2018
This is a really cool tale of reverse engineering. But the existence of this "feature", and how to activate it, was documented pretty well in the CPU's datasheet (page A-10)
I bet the presenter wishes he'd seen that! But yes I think the fun and interesting thing about this video is the journey more than the destination.
posted by fleacircus at 6:27 AM on September 7, 2018
I bet the presenter wishes he'd seen that! But yes I think the fun and interesting thing about this video is the journey more than the destination.
posted by fleacircus at 6:27 AM on September 7, 2018
Summary so far:
Hackers find and take control of an older, but likely universal, hidden and undocumented RISC core that VIA was embedded into their C3 x86 CPUs, and
VIA Is the third largest chip manufacturer and this chip family in particular is frequently embedded into systems like ATMs and healthcare devices. Many of these devices simply won’t be updated which makes this attack particularly problematic.
posted by zenon at 6:29 AM on September 7, 2018 [3 favorites]
Hackers find and take control of an older, but likely universal, hidden and undocumented RISC core that VIA was embedded into their C3 x86 CPUs, and
that this alternate core could be activated through special instructions, which would then allow it to circumvent processor security mechanisms. While this is vaguely reminiscent of the better-known Intel Management Engine (ME) and AMD Platform Security Processor (PSP), the VIA embedded core appeared to be much more tightly coupled with the x86 core
VIA Is the third largest chip manufacturer and this chip family in particular is frequently embedded into systems like ATMs and healthcare devices. Many of these devices simply won’t be updated which makes this attack particularly problematic.
posted by zenon at 6:29 AM on September 7, 2018 [3 favorites]
this is like finding a midget under your hat who can control your mind & body.
This is why I never wear a hat.
Seriously, though, the forensics & speculation involved in finding this seem pretty implausible. "We think there's an instruction that switches instruction sets." Fair enough -- that's like ARM/Thumb, although you don't know what the "other" instruction set is, or how to get back. But "we think there's an x86 instruction where the 32-bit immediate value is the instruction in the other instruction set." And then that turns out to be right! (Note, this is what I gather from the whitepaper. I am a patent attorney, not a code spelunker.)
posted by spacewrench at 6:29 AM on September 7, 2018 [1 favorite]
This is why I never wear a hat.
Seriously, though, the forensics & speculation involved in finding this seem pretty implausible. "We think there's an instruction that switches instruction sets." Fair enough -- that's like ARM/Thumb, although you don't know what the "other" instruction set is, or how to get back. But "we think there's an x86 instruction where the 32-bit immediate value is the instruction in the other instruction set." And then that turns out to be right! (Note, this is what I gather from the whitepaper. I am a patent attorney, not a code spelunker.)
posted by spacewrench at 6:29 AM on September 7, 2018 [1 favorite]
The authors note in the white paper (where the pullquote I posted above was grabbed from) that “VIA C3 processors were selected as the target of this research. We were unable to locate a VIA developer manual, such as those commonly offered by Intel and AMD, to gain any significant insights into the processor, so further research was based on testing, inferences from patent applications, and significant trial and error. ”
posted by zenon at 6:38 AM on September 7, 2018 [1 favorite]
posted by zenon at 6:38 AM on September 7, 2018 [1 favorite]
VIA Is the third largest chip manufacturer and this chip family in particular is frequently embedded into systems like ATMs and healthcare devices. Many of these devices simply won’t be updated which makes this attack particularly problematic.
The hope is that most of these systems are locked down to limit the avenues that someone can introduce malicious code into the embedded. I do understand that often doesn't meet reality though.
posted by jmauro at 6:50 AM on September 7, 2018
The hope is that most of these systems are locked down to limit the avenues that someone can introduce malicious code into the embedded. I do understand that often doesn't meet reality though.
posted by jmauro at 6:50 AM on September 7, 2018
Ruh Rho!
posted by SonInLawOfSam at 7:29 AM on September 7, 2018 [1 favorite]
posted by SonInLawOfSam at 7:29 AM on September 7, 2018 [1 favorite]
What does this gain VIA, the existence of this sekret core?
posted by maxwelton at 8:07 AM on September 7, 2018
posted by maxwelton at 8:07 AM on September 7, 2018
It means you can have production code running unmodified at the highest security level, and still debug it when things go wrong. Which can be useful on an embedded system... if you ignore that it's kinda buggering up the 'highest security level' concept... but not, as Dr Strangelove said, if you keep it a secret. VIA isn't writing the software, and if it isn't telling the people who do, then... huh.
It could be that VIA intended to make a sales feature of this but decided not to, or that it was doing it for a client who had a specific use for it. Short of finding code in the wild that uses this, or VIA coming clean, we may never know. Finding code may not be that difficult if; the mechanism for feeding instructions to the RISC core stands out like a sore Arm.
The fact that VIA patented things makes me think it was an aborted feature that cost too much to rip out when the core was finalised and had been through testing. You'd think that just knocking out the enabling bit in the appropriate register would be safe enough, but perhaps they still intended to do something with it at some point.
posted by Devonian at 8:33 AM on September 7, 2018 [2 favorites]
It could be that VIA intended to make a sales feature of this but decided not to, or that it was doing it for a client who had a specific use for it. Short of finding code in the wild that uses this, or VIA coming clean, we may never know. Finding code may not be that difficult if; the mechanism for feeding instructions to the RISC core stands out like a sore Arm.
The fact that VIA patented things makes me think it was an aborted feature that cost too much to rip out when the core was finalised and had been through testing. You'd think that just knocking out the enabling bit in the appropriate register would be safe enough, but perhaps they still intended to do something with it at some point.
posted by Devonian at 8:33 AM on September 7, 2018 [2 favorites]
Oh, this dude.
This is the guy who modified a C compiler so that emits only MOV instructions (because both he and the x86 instruction set are nutty). He's the first place you go to for weird CPU shit.
posted by It's Never Lurgi at 9:16 AM on September 7, 2018 [12 favorites]
This is the guy who modified a C compiler so that emits only MOV instructions (because both he and the x86 instruction set are nutty). He's the first place you go to for weird CPU shit.
posted by It's Never Lurgi at 9:16 AM on September 7, 2018 [12 favorites]
Ah, that explains why I was oddly disappointed when he only wrote an assembler, instead of going on to a Brainfuck compiler.
posted by Devonian at 10:38 AM on September 7, 2018 [2 favorites]
posted by Devonian at 10:38 AM on September 7, 2018 [2 favorites]
Chris Domas would be scary on his own. But when you consider there are probably several governments with whole goon squads of people like him secretly working on God-knows-what, that's really scary.
If you enjoyed this, I recommend the sinkhole talk.
posted by Western Infidels at 10:41 AM on September 7, 2018 [2 favorites]
If you enjoyed this, I recommend the sinkhole talk.
posted by Western Infidels at 10:41 AM on September 7, 2018 [2 favorites]
Finding code may not be that difficult if; the mechanism for feeding instructions to the RISC core stands out like a sore Arm.
ಠ_ಠ
posted by ChurchHatesTucker at 10:50 AM on September 7, 2018 [14 favorites]
the existence of this "feature", and how to activate it, was documented pretty well in the CPU's datasheet (page A-10). The sad thing is that no operating system (AFAIK) bothers to explicitly disable it.
So I'm looking at that datasheet (page A-10 is page 80 of the PDF, if anybody else is looking) and I'm looking at the white paper, and the white paper is all about how if God Mode is turned on then we can do this nefarious thing and that nefarious thing and the other nefarious thing and I'm thinking yeah, sure, but the datasheet specifically says that the ALTINST bit in the Feature Control Register defaults to Off and modifying the FCR requires a privileged instruction, so problem is where exactly? And then on page 11 of the white paper there is this:
It's not that operating systems are not bothering to explicitly disable it, because it comes up disabled from reset. If it's enabled by default on many systems, that has to be because those systems or their bootloaders are explicitly turning it on.
posted by flabdablet at 12:19 PM on September 7, 2018 [7 favorites]
So I'm looking at that datasheet (page A-10 is page 80 of the PDF, if anybody else is looking) and I'm looking at the white paper, and the white paper is all about how if God Mode is turned on then we can do this nefarious thing and that nefarious thing and the other nefarious thing and I'm thinking yeah, sure, but the datasheet specifically says that the ALTINST bit in the Feature Control Register defaults to Off and modifying the FCR requires a privileged instruction, so problem is where exactly? And then on page 11 of the white paper there is this:
In this example, it is assumed that the god mode bit is already set, activating the backdoor; while this, in theory, requires kernel level execution at some previous point in time, in section VII we demonstrate that the god mode bit is enabled by default on many systems, allowing any unprivileged code, with no prior access to the system, to immediately gain kernel level execution.and I'm like oh for FUCK's sake.
It's not that operating systems are not bothering to explicitly disable it, because it comes up disabled from reset. If it's enabled by default on many systems, that has to be because those systems or their bootloaders are explicitly turning it on.
posted by flabdablet at 12:19 PM on September 7, 2018 [7 favorites]
Is there any possibility that the Via C3 is implemented as a RISC machine that emulates x86, and this whole "alternate instruction" mode is just a trapdoor to the underlying CPU, rather than an honest-to-goodness parallel CPU?
The fact that every instruction has to be wrapped or bridged this way means programs double in size, cache sizes are effectively halved, etc. You certainly wouldn't use this mechanism to write a straightforward application. And I don't see a suggestion that the alternate mode can run in parallel with x86 mode.
You have to execute some x86 instructions to get alt-mode going, so what/how would this help you debug x86 code? If you've got a way to interrupt and trigger alt-mode on a bricked system, you've also got a way to interrupt and run x86 code, which is how most debuggers work.
posted by Western Infidels at 12:37 PM on September 7, 2018
The fact that every instruction has to be wrapped or bridged this way means programs double in size, cache sizes are effectively halved, etc. You certainly wouldn't use this mechanism to write a straightforward application. And I don't see a suggestion that the alternate mode can run in parallel with x86 mode.
You have to execute some x86 instructions to get alt-mode going, so what/how would this help you debug x86 code? If you've got a way to interrupt and trigger alt-mode on a bricked system, you've also got a way to interrupt and run x86 code, which is how most debuggers work.
posted by Western Infidels at 12:37 PM on September 7, 2018
One way I've reduced my personal misery level lately is by deleting my bookmarks to Hacker News.
Yet this is the kind of topic that makes sense to check out over there. There is a thread, some contributors there agree that the alt-mode is just access to the underlying hardware (although as far as I can see no one refers to an authoritative source on that).
Then they all bicker about what degree of dismissal and nastiness is warranted. Lovely. This is why I don't read HN anymore.
posted by Western Infidels at 12:51 PM on September 7, 2018 [2 favorites]
Yet this is the kind of topic that makes sense to check out over there. There is a thread, some contributors there agree that the alt-mode is just access to the underlying hardware (although as far as I can see no one refers to an authoritative source on that).
Then they all bicker about what degree of dismissal and nastiness is warranted. Lovely. This is why I don't read HN anymore.
posted by Western Infidels at 12:51 PM on September 7, 2018 [2 favorites]
I only use SIS chipsets.
posted by Jessica Savitch's Coke Spoon at 3:59 PM on September 7, 2018
posted by Jessica Savitch's Coke Spoon at 3:59 PM on September 7, 2018
That sinkhole thing is deeply scary. I have long thought of SMM as a feature that was wrong from the start, but actually seeing just how little code it takes to install the world's least detectable rootkit in a way that simply can't be prevented without physically replacing a CPU is quite alarming.
posted by flabdablet at 7:25 AM on September 8, 2018 [1 favorite]
posted by flabdablet at 7:25 AM on September 8, 2018 [1 favorite]
« Older Racial vs. Creedal Nationalism FTW | bitter medicine Newer »
This thread has been archived and is closed to new comments
posted by acb at 2:17 AM on September 7, 2018 [1 favorite]