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."
Is the separate RISC core actually on the silicon or just in the patent? Time to get out the fuming sulfuric acid.
I would be surprised if there wasn't a backdoor in any complex system, hardware or software.
Offended? Find a safe space and cry yourself to sleep.
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.
I don't trust the government to properly fill potholes in the streets let alone have a design review of CPU silicon.
Only the State obtains its revenue by coercion. - Murray Rothbard
In tge rwal warld, I like to use a spelings checker and proofs read my grammer before spending.
Bekause;
A) its a great feature !
2) its my preferable way to debuggings
4]. It stops tge aversary rite in there tracks!?
* More, over its less RISK than x86, AND, an nay SPARK's CPU.
,
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.
riiiight, last I checked the USA government wanted a backdoor in everything because citizens are to be treated like criminals by default.
I run this. No microscope required. :)
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I take backdoor to mean an undocumented thing that allows the developers to access something that the end user isn't supposed to be aware of. So by that definition it would be intentional yes. It may not be malicious in nature, or may even be considered an inside joke or easter egg, or maybe I am paranoid.
Offended? Find a safe space and cry yourself to sleep.
It is thought that only VIA C3 CPUs are affected by this issue. The C-series processors are marketed towards industrial automation, point-of-sale, ATM, and healthcare hardware, as well as a variety of consumer desktop and laptop computers.
Forget thin clients, if this shit is (still) controlling SCADA stuff then this is worse than the meltdown vulnerability.
Anons need not reply. Questions end with a question mark.
First this chip was designed at Centaur Technology in the US, a subsidiary of the main VIA. They design x86 processors, don't blame other crap on them.
Second this isn't a problem with the chip - it's a problem in software not configuring the chip correctly according to the documentation.
Third their x86 processors were designed for a specific market for which they are/were a good fit.
Over a decade ago I remember an article where ARPA? DoD? (someone with the resources and interest to do this) created a special limited CPU chip with "problems" and undocumented features. They gave them to different companies, and had their techs test to see if they could locate the problems.
I understand one was a root-escalation feature, and there were supposedly many others. The point was to see how many could be discovered by "the tech community" -- I presume they military was trying to figure out their exposure to the CPUs that THEY were getting. (see initial fight in Battlestar Galactica TNG where the human fleets are remotely shut down.)
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
Could be. I am a Centaur/VIA/WinChip enthusiast. Today I still run a VIA Esther, which is also known as the VIA C7. It is essentially an enhanced C3 and it would be interesting to see what's going on there. They're still a RISC core emulating x86 and I would guess that this exploit is probably still present.
These Centaur-derived VIA processors continue to be produced by VIA. When VIA bought Centaur and Cyrix, they ditched Cyrix and continued to evolve the Centaur platform. Some of the personnel from both companies stayed at VIA to work on the Centaur platform. VIA went on to sell the Cyrix IP to AMD who continues the Cyrix platform. The code names of the chips get blurred here when VIA worked on a couple of Cyrix chips that had Jewish code names which are assigned to Centaur chips.
Fun things to know and tell: Cyrix was a reverse-engineered CISC re-implementation of the Intel architecture, starting with math coprocessors and moving on to CPUs. In contrast, VIA/Centaur was an emulation of the Intel architecture actually running on a RISC core.
History says both approaches were right.
Kriston