Slashdot Mirror
Researcher Finds A Hidden 'God Mode' on Some Old x86 CPUs (tomshardware.com)
"Some x86 CPUs have hidden backdoors that let you seize root by sending a command to an undocumented RISC core that manages the main CPU," Tom's Hardware reports, citing a presentation by security researcher Christopher Domas at the Black Hat Briefings conference in Las Vegas.
The command -- ".byte 0x0f, 0x3f" in Linux -- "isn't supposed to exist, doesn't have a name, and gives you root right away," Domas said, adding that he calls it "God Mode." The backdoor completely breaks the protection-ring model of operating-system security, in which the OS kernel runs in ring 0, device drivers run in rings 1 and 2, and user applications and interfaces ("userland") run in ring 3, furthest from the kernel and with the least privileges. To put it simply, Domas' God Mode takes you from the outermost to the innermost ring in four bytes. "We have direct ring 3 to ring 0 hardware privilege escalation," Domas said. "This has never been done.... It's a secret, co-located core buried alongside the x86 chip. It has unrestricted access to the x86."
The good news is that, as far as Domas knows, this backdoor exists only on VIA C3 Nehemiah chips made in 2003 and used in embedded systems and thin clients. The bad news is that it's entirely possible that such hidden backdoors exist on many other chipsets. "These black boxes that we're trusting are things that we have no way to look into," he said. "These backdoors probably exist elsewhere." Domas discovered the backdoor, which exists on VIA C3 Nehemiah chips made in 2003, by combing through filed patents.
"Some of the VIA C3 x86 processors have God Mode enabled by default," Domas adds. "You can reach it from userland. Antivirus software, ASLR and all the other security mitigations are useless."
The good news is that, as far as Domas knows, this backdoor exists only on VIA C3 Nehemiah chips made in 2003 and used in embedded systems and thin clients. The bad news is that it's entirely possible that such hidden backdoors exist on many other chipsets. "These black boxes that we're trusting are things that we have no way to look into," he said. "These backdoors probably exist elsewhere." Domas discovered the backdoor, which exists on VIA C3 Nehemiah chips made in 2003, by combing through filed patents.
"Some of the VIA C3 x86 processors have God Mode enabled by default," Domas adds. "You can reach it from userland. Antivirus software, ASLR and all the other security mitigations are useless."
It is real alright. Same with the Intel management engine and the AMD PSP.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
If you RTFA you will see that the patent hinted at it's presence and then he found it on real hardware by fuzzing.
From the datasheet itself:
ALTERNATE INSTRUCTION EXECUTION
When set to 1, the ALTINST bit in the FCR enables execution of an alternate (not x86) instruction set. While setting this FCR bit is a privileged operation, executing the alternate instructions can be done from any protection level.
This alternate instruction set includes an extended set of integer, MMX, floating-point, and 3DNow! instructions along with additional registers and some more powerful instruction forms over the x86 instruction architecture. 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 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.
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 alter- nate instructions. This new jump instruction can be executed from any privilege level at any time that ALTINST is 1. The new jump instruction is a two-byte instruction: 0x0F3F. If ALTINST is 0, the execution of 0x0F3F causes an Invalid Instruction exception.
3. When executed, the new 0x0F3F x86 instruction causes a near branch to CS:EAX. That is, the branch function is the same as the existing x86 instruction
jmp [eax]
In addition to the branch, the 0x0F3F instruction sets the processor into an internal mode where the target bytes are not interpreted as x86 instructions but rather as alternate instruction set instructions.
4. The alternate instructions fetched following the 0x0F3F branch should be of the form
0x8D8400XXXXXXXX where 0xXXXXXXXX is the 32-bit alternate instruction
That is, the alternate instructions are presented as the 32-bit displacement of a
LEA [EAX+EAX+disp]
instruction. This example assumes that the current code segment size is 32-bits, if it is 16-bits, then an address size prefix (0x67) must be placed in front of the LEA opcode.
5. Upon fetching, the LEA “wrapper” is stripped off and the 32-bit alternate instruction contained in the displacement field is executed.
6. The alternate instruction set contains a special branch instruction that returns control to x86 fetch and execute mode. The x86 state upon return is not necessarily what it was when alternate instruction execution is entered since the alternate instructions can completely modify the x86 state.
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.
VIA is cheap. Back in the C3 days they had a bit of popularity among the people who wanted a compact server, firewall or media box. Decently fast but cool running CPUs, and good silent fans were all a pretty new development back then, so there wasn't that much choice.
So I tried.
The Nehemiah CPU was a dog. The network card corrupted some of the outgoing packets, and it was visible by naked eye by just refreshing a page served by the box and seeing how a character was wrong somewhere. Sticking a system in a small box looked pretty, but the tiny fan was noisy as hell, and it killed the hard disk from the overheating after a while. There was some kind of trouble with the power supply. Accounting for the time I spent screwing around with that junk, it would have been far cheaper to just buy a normal board with a normal CPU.
With the luck I've had with this specific product line, I'm amazed some of it is still alive today.
It is highly unlikely to be a separate core. It is a separate instruction decoder, allowing access to the underlying pipeline. The fact that the data sheet says the x86 state may be different is a dead giveaway.
Most CISC style machines are something else RISC like under the hood, with the CISC ISA ‘interpreted’ by a complex instruction decoder / sequencer and microcode. In this case, there are ‘just’ extra decodes (and likely microcode lines) that are a available when the control reg bit is set.
Auditable hardware and microcode, if you really care about security.
Aighearach for some reason won't answer you directly, but I will. Fuzzing is when you essentially throw piles of random data at something, usually to try to get it to break. Like if you were building a web browser, you know it works when the HTML is valid, but what if it isn't? What if it not only isn't but what if it is total random garbage? What if it is total random garbage that is 100MB large? You throw "fuzz" at it and see if it triggers any problems. In this case, they probably tried all sorts of invalid opcodes and used all sorts of random data in the registers until they found this
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I don't think it's a separate RISC core. It's likely the main RISC core running x86 code. You see, for every processor of Pentium Pro era and afterwards, the "CPU" doesn't execute x86 instructions. Instead, there's a RISC core and a dynamic instruction translator that converts x86 instructions into RISC instructions.
On Intel at least the x86 "front end" consists of around 3-4 "instruction crackers" that can take relatively simple x86 instructions and emit up to 2-3 RISC instructions every clock cycle. There is also a more complex instruction unit that handles the complex x86 instructions. Attached to this is a cache so if the same instruction comes around again, it's not translated but simply re-issues the instructions again.
This is one reason why Spectre and Meltdown were particularly bad on Intel - as the core is relatively independent it will cache things that architecturally it shouldn't but the core didn't know any better.
And no, no x86 natively runs x86 code anymore - it's all dynamically translated into an underlying RISC machine. Nonetheless, Spectre attacks are on general optimizations made which affect all architectures using those optimizations.
As for why this processor allows this mode, I can think it's for special software implemented features - instead of implementing things in hardware, sometimes it's done in software and drivers can use this gateway to turn off the x86 translator and run native RISC code directly for performance reasons. Centaur is not a particularly fast chip, so being able to optimize heavy media applications by dropping into the native RISC mode can speed up things at the driver level.