Christopher Domas: Hardware Backdoors in X86 CPUs
github.com
github.com
And now someone has discovered that sometimes you can enter debug mode from ring 3 and they're calling it a backdoor.
Granted, you can disable single user mode.
"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.
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.
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? :/
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.
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.
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.
Clickbait title in my opinion, they wanted the casual observer to confuse this with Intel/AMD at first glance.
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.
BTW there's an interesting documentary about Centaur, free to watch on Prime Video.
https://www.amazon.com/Rise-Centaur-Glenn-Henry/dp/B01FSZU6F...
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.
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.
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.
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.
That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.
It would be much more of a problem if these were consumer machines running untrusted code.
What is the use of this feature?
"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.
When chips have these undocumented co-processors in them with unlimited privilege to the system, sooner or later they're going to be exploited.
/me sets up his x-ray machine
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.
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 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?
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.
Security people will just move the goalposts to "we assume the actual chip has backdoors that aren't present in public source code".
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.