Christopher Domas: Hardware Backdoors in X86 CPUs(github.com)
github.com
Christopher Domas: Hardware Backdoors in X86 CPUs
https://github.com/xoreaxeaxeax/rosenbridge
67 comments
This. When I read the article I instantly recognised this from some datasheet-browsing I did many years ago. It's not a "coprocessor", it's not a backdoor, it's just access to the internal core. It's even documented in the datasheet itself:
http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...
(Page 82, "Alternate Instruction Execution")
Edit: Now it's all coming back to me. I was exploring the 0F opcode space and came upon 0F 3F, which happens to be the "enter alternate execution mode" instruction when it's enabled. There are a lot of other interesting results if you Google "0F 3F", although I remember them being a lot more relevant when I originally discovered this...
https://spth.virii.lu/29a7/Articles/29A-7.029.txt
It's not just the C3 that has this feature, if you Google "ALTINST" you'll find more info.
http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia...
(Page 82, "Alternate Instruction Execution")
Edit: Now it's all coming back to me. I was exploring the 0F opcode space and came upon 0F 3F, which happens to be the "enter alternate execution mode" instruction when it's enabled. There are a lot of other interesting results if you Google "0F 3F", although I remember them being a lot more relevant when I originally discovered this...
https://spth.virii.lu/29a7/Articles/29A-7.029.txt
It's not just the C3 that has this feature, if you Google "ALTINST" you'll find more info.
While it is (a bit disappointingly) a known instruction, it seems that Domas has came up with this by his own (via sandsifter [1]). Also, it is really unexpected that there is a documented userland instruction that goes to ring 0 anyway, so it is a "documented" "backdoor". In any case I still think that this study is interesting, mainly because it shows that we can inspect such instructions seemingly out of nowhere.
[1] https://github.com/xoreaxeaxeax/sandsifter
[1] https://github.com/xoreaxeaxeax/sandsifter
"It's just access to the internal core"
For which the instruction set is not documented. For which the x86 access instruction ("bound eax") is not documented. For which the capabilities are not documented. From which you can circumvent all of the processor's security checks.
This is a _textbook_ definition of a backdoor.
For which the instruction set is not documented. For which the x86 access instruction ("bound eax") is not documented. For which the capabilities are not documented. From which you can circumvent all of the processor's security checks.
This is a _textbook_ definition of a backdoor.
> For which the instruction set is not documented.
Why does it matter?
This alternate instruction set is intended for testing, debug, and special application usage. Accordingly, it is not documented for general usage. If you have a justified need for access to these instructions, contact your VIA representative.
> For which the x86 access instruction ("bound eax") is not documented.
The instruction is documented to be LEA (which I presume is correct for this particular processor) and:
While all VIA C3 processor processors contain this alternate instruction feature, the invocation details (e.g., the 0x8D8400 “prefix”) may be different between processors. Check the appropriate processor data sheet for details.
> For which the capabilities are not documented.
It's documented that you can do pretty much anything:
For example, in the alternate instruction set, privileged functions can be used from any protection level, memory descriptor checking can be bypassed, and many x86 exceptions such as alignment check can be bypassed.
> This is a _textbook_ definition of a backdoor.
No.
Why does it matter?
This alternate instruction set is intended for testing, debug, and special application usage. Accordingly, it is not documented for general usage. If you have a justified need for access to these instructions, contact your VIA representative.
> For which the x86 access instruction ("bound eax") is not documented.
The instruction is documented to be LEA (which I presume is correct for this particular processor) and:
While all VIA C3 processor processors contain this alternate instruction feature, the invocation details (e.g., the 0x8D8400 “prefix”) may be different between processors. Check the appropriate processor data sheet for details.
> For which the capabilities are not documented.
It's documented that you can do pretty much anything:
For example, in the alternate instruction set, privileged functions can be used from any protection level, memory descriptor checking can be bypassed, and many x86 exceptions such as alignment check can be bypassed.
> This is a _textbook_ definition of a backdoor.
No.
Ah, this kind of deflates things a bit, heh. But then concrete knowledge is better than hype, so this is still interesting.
But the fact that you can twiddle kernel memory from userspace is still fun...
I still wonder why entering debug mode got enabled on some models, but not others. 11th-hour release-to-fab glitch? :/
But the fact that you can twiddle kernel memory from userspace is still fun...
I still wonder why entering debug mode got enabled on some models, but not others. 11th-hour release-to-fab glitch? :/
This is an irritating comment, I don't understand some people's urge to disparage others' research even at the expense of rationality.
Even modern Intel and AMD processors are "RISC" under the hood - they decompose CISC x86 instructions into RISC micro-ops, this isn't a VIA phenomenon. But they DON'T open up access to their microcode to some arbitrary user letting you circumvent ring protections to access the kernel from ring 3. If they did that would be a - wait for it - backdoor.
Even modern Intel and AMD processors are "RISC" under the hood - they decompose CISC x86 instructions into RISC micro-ops, this isn't a VIA phenomenon. But they DON'T open up access to their microcode to some arbitrary user letting you circumvent ring protections to access the kernel from ring 3. If they did that would be a - wait for it - backdoor.
How is it not a backdoor? Just because it's unintended or due to a very complex reason doesn't mean it's not one.
Not a backdoor; more accurately described as "lack of a door".
Well, if it's a documented feature, I'd call it that. You don't call "single user mode" a backdoor.
Granted, you can disable single user mode.
Granted, you can disable single user mode.
I'd call it a glaring design flaw. And if very, very few users might notice that documentation, then I'd call it a backdoor hidden in plain sight. For all intents and purposes it really is a backdoor.
According to the datasheet, this is by design:
"The mechanism for initiating execution of this alternate set of instructions is as follows: 1. Set the FCR ALTINST bit to 1 using WRMSR instruction (this is a privileged instruction). This should be done using a read-modify-write sequence to preserve the values of other FCR bits. 2. The ALTINST bit enables execution of a new x86 jump instruction that starts execution of alternate instructions. This new jump instruction can be executed from any privilege level at any time that ALTINST is 1."
So to turn on the ability to execute ring-0 non-x86 instructions from ring 3, requires an initial privileged instruction. I believe (from other commenters) that the issue arises because some of the cpu's left the fab with ALTINST set to 1 by default. Meaning, no privileged instruction required. Clearly, that's a fuck-up somewhere.
"The mechanism for initiating execution of this alternate set of instructions is as follows: 1. Set the FCR ALTINST bit to 1 using WRMSR instruction (this is a privileged instruction). This should be done using a read-modify-write sequence to preserve the values of other FCR bits. 2. The ALTINST bit enables execution of a new x86 jump instruction that starts execution of alternate instructions. This new jump instruction can be executed from any privilege level at any time that ALTINST is 1."
So to turn on the ability to execute ring-0 non-x86 instructions from ring 3, requires an initial privileged instruction. I believe (from other commenters) that the issue arises because some of the cpu's left the fab with ALTINST set to 1 by default. Meaning, no privileged instruction required. Clearly, that's a fuck-up somewhere.
Not every security vulnerability is a backdoor. (The Intel ME isn't a backdoor either.)
You're being either overly generous to Intel or you're underestimating how well funded some of the espionage organization really are. And consider that for decades espionage organizations have been taking advantage of bugs in commercial products. This is so well documented at this point that it's not even worth arguing. Personally I believe this has been going on since the '70's.
Well-funded espionage organizations can exploit almost everything, so almost everything is a backdoor? Is that a useful definition?
"Thieves can break windows so there's no need to lock your doors". Fallacy.
What is a backdoor? A set of secret instructions that lets you get control or access over target machine.
Exactly what this is. Re-read the README.
Couldn't resist:
https://www.youtube.com/watch?v=ahcVp8vIicI&t=20s
https://www.youtube.com/watch?v=ahcVp8vIicI&t=20s
Waits for Chris Domas to write an LLVM backend for the internal RISC target so we can get 1337 performance out of our C3's.
They so clearly titled this "X86 CPUs" instead of "VIA C3 CPUs" or "VIA C3 x86 CPUs" on purpose.
Clickbait title in my opinion, they wanted the casual observer to confuse this with Intel/AMD at first glance.
Clickbait title in my opinion, they wanted the casual observer to confuse this with Intel/AMD at first glance.
This is by the same badass who wrote a compiler that generates only MOV instructons [1]
[1] https://github.com/xoreaxeaxeax/movfuscator
[1] https://github.com/xoreaxeaxeax/movfuscator
From the FAQ:
Q: Why did you make this? A: I thought it would be funny.
Thanks for that little side-bar/rabbit-hole. Fascinating, as is the paper he based it on. I'm itching to get home and try this out - specifically, I'm interested on what the performance might be like.
performance: something that takes seconds now takes hours.
ah, here it is - branchless doom (in the validation/doom directory - https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali... ):
> The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
ah, here it is - branchless doom (in the validation/doom directory - https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali... ):
> The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
These were designed by Centaur Technology (based in Austin, TX), I'd love to hear from any alums (danluu?) what the purpose of the coprocessor is.
BTW there's an interesting documentary about Centaur, free to watch on Prime Video.
https://www.amazon.com/Rise-Centaur-Glenn-Henry/dp/B01FSZU6F...
BTW there's an interesting documentary about Centaur, free to watch on Prime Video.
https://www.amazon.com/Rise-Centaur-Glenn-Henry/dp/B01FSZU6F...
> I'd love to hear from any alums (danluu?) what the purpose of the coprocessor is.
Absolutely agree there, I can imagine it being ridiculously interesting.
But the truth might also be equal parts boring and scary instead. I mean...
> The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
> The core executes these commands (which we call the 'deeply embedded instruction set'), bypassing all memory protections and privilege checks.
> The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU's memory, but its register file and execution pipeline as well.
This is enough anti-plausible-deniability that I can just sweepingly point everybody in the direction of the big fat (flashing!) elephant in the room and the "..." sitting next to it.
I mean, VIA didn't have as much success as Intel or AMD, but they are a known name. Anything that implements x86 is going to have market penetration to some extent, and VIA achieved success in the industrial and embedded sectors.
If danluu was able to comment here and debunk what I'm saying, I would be both very surprised and even more delighted.
Absolutely agree there, I can imagine it being ridiculously interesting.
But the truth might also be equal parts boring and scary instead. I mean...
> The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
> The core executes these commands (which we call the 'deeply embedded instruction set'), bypassing all memory protections and privilege checks.
> The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU's memory, but its register file and execution pipeline as well.
This is enough anti-plausible-deniability that I can just sweepingly point everybody in the direction of the big fat (flashing!) elephant in the room and the "..." sitting next to it.
I mean, VIA didn't have as much success as Intel or AMD, but they are a known name. Anything that implements x86 is going to have market penetration to some extent, and VIA achieved success in the industrial and embedded sectors.
If danluu was able to comment here and debunk what I'm saying, I would be both very surprised and even more delighted.
If I knew anything non-public (and in this case I don't -- this is from before my time there), I wouldn't be able to talk about it :-)
This has now been pointed out in another thread, but this feature is documented in the datasheet here: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia.... See Appendix A, A-9 & A-10, as well as the section on CPUID bits.
This has now been pointed out in another thread, but this feature is documented in the datasheet here: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia.... See Appendix A, A-9 & A-10, as well as the section on CPUID bits.
Title should be renamed to: Hardware Backdoors in Obscure x86 CPUs made in 2003.
... and embedded in ATMs with a 20 year life span.
Your comment sounds a bit dismissive of the vulnerability with an implication that it would never be a problem. If that was not what you were implying I apologize. It is critical that even "old" chips vulnerabilities be understood so that one can understand the risks. It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.
Your comment sounds a bit dismissive of the vulnerability with an implication that it would never be a problem. If that was not what you were implying I apologize. It is critical that even "old" chips vulnerabilities be understood so that one can understand the risks. It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.
> ... and embedded in ATMs with a 20 year life span.
Privilege escalation is not a problem on ATMs.
> It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.
Why? Just treat it as you do most hardware, under full control of whatever you attach it to. Zero security present, zero security needed.
Privilege escalation is not a problem on ATMs.
> It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.
Why? Just treat it as you do most hardware, under full control of whatever you attach it to. Zero security present, zero security needed.
> Privilege escalation is not a problem on ATMs.
https://vuldb.com/?id.79002
https://vuldb.com/?id.79002
I expect that most people miss that ATM manufacturers continue to put security holes in ATMs (https://www.wired.com/2014/11/nashville/) one of the 'fixes' was to make bank access unprivileged. But wait, if I have an escalation vulnerability ...
Sigh. Okay let me rephrase. The thing normally called "privilege escalation", where software that is executing on a machine escapes a sandbox or gets into kernel mode, is not a problem on ATMs.
That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.
That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.
This can be combined with another exploit that allows the user to execute user code to achieve root on the ATM, so it's still troubling.
Privilege escalations come in many shapes and sizes, it is not limited to software escaping a sandbox or to get into kernel mode, it is also explicitly used to refer to users of a system managing to leverage their normal access into a more powerful one.
But in context I was clearly talking about the former, because the topic is software exploiting CPU backdoors.
I don’t think these ATMs run a lot of untrusted code, and this is of course easily patched by clearing the bit during the boot sequence.
It would be much more of a problem if these were consumer machines running untrusted code.
It would be much more of a problem if these were consumer machines running untrusted code.
I don't think minimizing the significance of the exploit should happen in the headline, but saying "x86 CPUs" instead of "Via CPUs" in the headline is very clickbaity.
"Via x86 CPUs" would be perfect. It conveys detailed information to those with detailed knowledge while still being understandable to those less familiar with tertiary cpu manufacturers.
Still, the consequences are huge. Also, how can we be sure something similar isn't implemented in modern CPUs?
This is absolutely implemented in modern CPUs, as debug or management features. Usually switched off - being able to turn it on from ring 3 would be a massive bug.
> VIA processors are renowned for their low power usage and excellence in embedded designs; we believe that the functionality described was created in good faith as a useful feature for the embedded market, and was unintentionally left enabled on some early generations of the processor.
What is the use of this feature?
What is the use of this feature?
I could see using a secondary core as a watchdog in an embedded environment-- if something went too wrong, perhaps the secondary CPU can either get some valuable logging data or stuff the system with code designed to restore it to a controllable state.
We should go back to real mode. Imagine all the sudden possibilities. No pesky memory barriers, no protection faults and superb integration of applications of all kind. Application could even share the same memory and the better one wins.
"If nothing is secure, everything is secure" - Lincoln
But seriously: I don't think this "feature" is a real backdoor. It is nonetheless an interesting topic.
I am more concerned about bugs and backdoors in modules like TPM/ME or other even less documented surprises. Wouldn't be the first time that happened and we can only hope, that better people find these type of vulnerability first.
"If nothing is secure, everything is secure" - Lincoln
But seriously: I don't think this "feature" is a real backdoor. It is nonetheless an interesting topic.
I am more concerned about bugs and backdoors in modules like TPM/ME or other even less documented surprises. Wouldn't be the first time that happened and we can only hope, that better people find these type of vulnerability first.
Sandsifter was pure genius, I can't wait to read the whitepaper for this one!
The talk is worth its weight in gold https://www.youtube.com/watch?v=KrksBdWcZgQ
Seems via specific? Rather than “all x86”
This is still a huge target. I used to be in point of sale engineering, and the majority of the quality terminals the big OEMs(NCR and their sub brands, posiflex, etc) were pushing were running these for a LONG time past when you'd think C3 was "dead". Similar vendors i bumped into were pushing stuff with them in it still when i got out of that industry.
There are a LOT of machines out there which will be run essentially until they break down(and a lot are fanless, and will pretty much last until they can't be kept up to date). You have to remember, a lot of big chains(and banks!) paid for extended XP support and then extended-extended XP in the form of windows POS.
This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.
There are a LOT of machines out there which will be run essentially until they break down(and a lot are fanless, and will pretty much last until they can't be kept up to date). You have to remember, a lot of big chains(and banks!) paid for extended XP support and then extended-extended XP in the form of windows POS.
This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.
>This is a "every terminal in a huge fast food chain gets owned and no one finds out for years" sort of vulnerability. This is the first step to something like the target breach all over again.
Utter nonsense, this bug will not lead to RCE.
You might be able to implement a fancy rootkit with this, but that's all. Advanced rootkit tech is neither necessary nor particularly helpful for these sorts of breaches.
Utter nonsense, this bug will not lead to RCE.
You might be able to implement a fancy rootkit with this, but that's all. Advanced rootkit tech is neither necessary nor particularly helpful for these sorts of breaches.
It is highly specific, yes. But who knows what else is lurking?
When chips have these undocumented co-processors in them with unlimited privilege to the system, sooner or later they're going to be exploited.
When chips have these undocumented co-processors in them with unlimited privilege to the system, sooner or later they're going to be exploited.
Yeah it opens my eyes on the real life implementation of processors, it's not just x86 assembly, a chip is free to have anything in it.
/me sets up his x-ray machine
/me sets up his x-ray machine
Documented instruction set switch which is just implemented poorly. But the real news here seems to be that the ALTINST is set to 1 by default in some C3 generations.
This is a HUGE wake-up call.
It really is incredible to see that a third party apparently has discovered a genuine backdoor in a production CPU with completely independent research. If that's within reach for a standalone researcher, what secrets lie in well-funded organizations at the nation level?
Perhaps this will bring further mindshare to the RISC-V approach in the future?
It really is incredible to see that a third party apparently has discovered a genuine backdoor in a production CPU with completely independent research. If that's within reach for a standalone researcher, what secrets lie in well-funded organizations at the nation level?
Perhaps this will bring further mindshare to the RISC-V approach in the future?
Perhaps this will bring further mindshare to the RISC-V approach in the future?
Security people will just move the goalposts to "we assume the actual chip has backdoors that aren't present in public source code".
Security people will just move the goalposts to "we assume the actual chip has backdoors that aren't present in public source code".
Personally I'd love to see a CISC-V --- the world really doesn't need any more MIPS-lookalikes, and a formal spec of x86 would be extremely useful for everyone from emulator writers to maybe even Intel itself.
That would be nice, but I'm more hopeful in the immediate for openpower to gain widespread usage on the desktop. Google seems to be banking on it for servers, at the very least.
Isn't openpower not actually very open? At least with RISCV we can compete vendors while maintaining a compatible instruction set, I'm not sure how many people are going to produce openpower chips.
In the long term, I think you have a point here. It would be nice to have IBM not being the only producer of, say, the POWER15. In that sense RISC-V is substantially more open than OpenPOWER.
But parent was talking about in the immediate timeframe, and right now (and I predict for the next few years at minimum), if you want free(r) and ballpark performance class with x86, then you're going to have to play with POWER. I don't think ARM is there yet with respect to grunt and some ARM designs have some of the same concerns about creepy dark corners of the processor die. It's why there's a Talos II under my desk.
But parent was talking about in the immediate timeframe, and right now (and I predict for the next few years at minimum), if you want free(r) and ballpark performance class with x86, then you're going to have to play with POWER. I don't think ARM is there yet with respect to grunt and some ARM designs have some of the same concerns about creepy dark corners of the processor die. It's why there's a Talos II under my desk.
I wanted one of those, just couldn't justify the price. I've been toying with the idea of running Reactos or Haiku on an FPGA as a cheaper "you own it as much as possible" variant.
This affects CPUs made in 2003 by Via, largely. If you use an ATM as your daily driver to browser the internet, this would be a problem.
This is absolutely insane! With all the recent bugs and features that looks like backdoors I have completely lost faith in x86.
We need simple open ISAs (like RISC-V) and a handfull of trusted organizations that inspect the manufacture processes to protect ourselves from this. A bit like how countries and organizations send people to inspect other countries democratic voting processes, or like how IAEA inspect nuclear stockpiles etc.
I call for:
+ Open source.
+ No creeping featurism.
+ Multiple inspection organizations that watch the process from source code to final chip product.
We need simple open ISAs (like RISC-V) and a handfull of trusted organizations that inspect the manufacture processes to protect ourselves from this. A bit like how countries and organizations send people to inspect other countries democratic voting processes, or like how IAEA inspect nuclear stockpiles etc.
I call for:
+ Open source.
+ No creeping featurism.
+ Multiple inspection organizations that watch the process from source code to final chip product.
And now someone has discovered that sometimes you can enter debug mode from ring 3 and they're calling it a backdoor.