Researcher Finds A Hidden 'God Mode' on Some Old x86 CPUs (tomshardware.com) 114
"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 it on the die? (Score:4, Interesting)
Re:Is it on the die? (Score:5, Informative)
It is real alright. Same with the Intel management engine and the AMD PSP.
"monster" CPU Re:Is it on the die? (Score:4, Interesting)
I run this [monster6502.com]. No microscope required. :)
Re: "monster" CPU Re:Is it on the die? (Score:1)
No you don't.
Re: "monster" CPU Re:Is it on the die? (Score:2)
At a clock speed of 60 KHz? I guess that pretty much rules out a GUI, LOL...
Re:Is it on the die? (Score:5, Informative)
If you RTFA you will see that the patent hinted at it's presence and then he found it on real hardware by fuzzing.
Re:Is it on the die? (Score:4, Insightful)
Lot of work to find something (partially) documented. Sandpile lists the instruction as ALTINST, the code is documented by VIA as used for testing with an MSR (Machine Specific Register) bit to enable it. If not enabled I assume it would be treated as an illegal instruction.
That some machine with a C3 processor didn't set the correct machine configuration is bad but not the end of the world - just set it correctly in the OS instead.
Re:Is it on the die? (Score:5, Interesting)
And he could save a lot of time by reading the manual for the processor as its a documented feature (ALTERNATE INSTRUCTION EXECUTION )...
Re: (Score:2, Interesting)
Bullshit, you got that from the wikipedia which was written 10 august 2018 ! HAHA.
Re: (Score:2)
Nope.
http://datasheets.chipdb.org/V... [chipdb.org]
Re: (Score:2)
Re: (Score:2)
Try "fuzzing code" instead. Or if you weren't sure and you said it like "Fuzzing (programming)" or "fuzzing computers" it would also work. Never say "microcode." Just know that microcode is a type of code, and use the word "code" until and unless you understand the difference and have a good reason to say microcode. If differentiates between things that only need to be differentiated if you have an additional use case related to the technology.
Re:Is it on the die? (Score:5, Informative)
Re: (Score:2)
slight delta (Score:2)
Fuzzing is when you essentially throw piles of random data at something, usually to try to get it to break.
Note that, though throwing random junk may be productive, the data is typically mostly valid stuff with some pseudo-random ignoring-spec-limits modifications. That way you get into the guts of the responding system where the violation may trigger a bug that you otherwise can't get near.
Total junk tends to hit some bail-out before it gets deep enough to be useful. You try that, too, because you never
Re: (Score:2)
Re: (Score:3)
With fuzzing, you just send random data to whatever input stream you are trying to test. This could be text processing, TCP/IP packets sent to a server socket, or machine-code instructions to a CPU. In this case, every bad instruction should be trapped and good instructions should be processed.
Re: (Score:2, Informative)
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
Re: (Score:1)
I wouldn't worry about it.
this backdoor exists only on VIA C3 Nehemiah chips made in 2003 and used in embedded systems and thin clients
The "article" is pure FUD.
Re:Is it on the die? (Score:5, Informative)
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.
Re: (Score:2)
did VIA ever do anything right? (Score:1)
Their chipsets have always been hot garbage. Their x86 chips are already dog slow, now this? How was VIA even a thing?
Re:did VIA ever do anything right? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:1)
... unless the card tells the kernel that it has receive TCP checksum offload, and then fucks it up to match. :-)
Re: (Score:2)
The TCP checksum is literally a sum. It's not a MD5, CRC or anything fancy like that. As a result it's not that hard for something to slip past it.
It's been a long time since then, but recall the network performance was awful, which would be consistent with packets that are detected as bad being dropped by the kernel and causing a retransmission.
The error rate was absolutely awful too, I'm not talking about something that happened once a month. I think the error happened pretty much always and in a consiste
Re: (Score:1)
TCP's error detection is fairly weak. A 16-bit CRC can only hope to catch 1 out of 65536 errors. At modern speeds, with flaky hardware that's barely working, it doesn't take long to accumulate 65536 errors, and then one of them is slipping through undetected. For the most part, the only reason we don't see a lot of errors with TCP is because our hardware is quite reliable and rarely generates any.
Re: (Score:2)
I often have to do run a check on downloaded Steam games. With several gigabytes of data, I guess the chance of something being off is small but not insignificant.
Re: (Score:1)
TCP's error detection is fairly weak. A 16-bit CRC can only hope to catch 1 out of 65536 errors.
That is not how CRC works. Maybe you are thinking about hash collisions?
A 1-bit CRC (Also known as a parity bit) is guaranteed to catch any single bit errors in a packet.
For a 16-bit CRC you can pick a polynomial that is guaranteed to detect any combination of 3 bit errors in a 64 kbit sequence or another that will catch up to 4 random bit errors in a 32 kbit sequence.
No algorithm can catch an arbitrary number of bit errors.
Some algorithms are made so that they are better at catching "burst errors" (Several
Re: (Score:2)
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.
I had a Nehemiah for a few years as I wanted a silent, low-power system. It was fine in an open case with a large passive heatsink. Those tiny-whiny fans on Mini-ITX systems are idiotic as they basically maintain the same power density. You can get completely silent systems in a regular ATX size if you choose these "mini" components and let them breathe.
For stronger systems with discrete GPUs, it's hard to get completely fanless, but third party coolers with large fans can get asymptotically close to sil
Re: did VIA ever do anything right? (Score:1)
So you're saying that how Nehemiah did its Job led to Lamentations?
Re:did VIA ever do anything right? (Score:4, Insightful)
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.
Re: (Score:2)
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.
I'll tell you the same thing I tell people when they say the same thing about Sony. If they don't want me to look down on all their products, they can stop putting one name on all their products. VIA wanted their name on that CPU, they can deal with the fallout now.
Re: (Score:2)
VIA used to make decent, inexpensive motherboards back in the 90s.
I had nothing but problems with them, so I'm going to call shenanigans there. That was a big problem with AMD back in the day before they made all their own chipsets. Intel made their own, and they cost a lot more than VIA, but they were a lot better, too. Intel on Intel, solid. AMD on AMD, solid. Either on VIA, terrible.
Re: (Score:2)
Inexpensive, yes. Decent? No way. VIA's stuff is garbage.
I won't even deal with VIA anymore. If I find/get an old PC and it has a VIA chipset, I just scrap it for parts. Not worth the hassle.
Not always a bad thing (Score:1)
Ok, this IS always a bad thing for the typical end user, but I can see two rwal-world use cases:
* For debugging. In this case, the customer wants the fearure. For the general case, there are better, safer ways of debugging, but there nay be cases where this is preferable.
* Espionage, in which case tge real customer - your aversary - wants the feature.
Beyond this, there isn't much point.
Re: (Score:3, Insightful)
Re: (Score:2)
Surprise Re:Not always a bad thing (Score:1)
There are plenty of complex systems with no "backdoors."
I assume "backdoor" means an intentional feature, not an unintentional security bug. If you meant an unintentionall bug, then we agree.
I also assume "the complex system" as the part that was built, not the hardware or software levels below "the system.". That is, if you claim all complex OSes that are sold independently of hardware have backdoors, you are claiming that these backdoors exist regardless of which hardware they run on, as long as the hard
Re: (Score:2)
Re: (Score:1)
I would be surprised if there wasn't a backdoor in any complex system, hardware or software.
^ This. It's naive to imagine that the NSA hasn't pwned every significant CPU and OS that sees more than niche uses.
That's the bad news. The good news is they don't care about you. (Unless you're a "person of interest").
Re:Not always a bad thing (Score:4, Interesting)
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.)
Re: Not always a bad thing (Score:2, Funny)
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.
,
Re: Backdoor to God? (Score:1)
son of God and Mary
Doesn't that make God a rapist?
Re: (Score:1)
Well 2 questions was Mary legal at the time ( according to the laws on the books at that time) and did she concent?
Re: Backdoor to God? (Score:2)
God didn't 'penetrate' Mary, God impregnated her - humans have to 'penetrate' (personally or mechanically) to impregnate a woman, God not so much.
Don't confuse what God did to Mary with what you and your distant cousin did on that family camping trip in the tent.
Re: REMEMBER (Score:2)
We should kill the guy who killed Ian!
Oh ... wait ...
Re: (Score:1)
You're right, it was part of the debuging core, which is present on most current cisc, risc and mips cpu's.
It could be disabled by sending a four byte sequence to the cpu during bootup, mostly done when the bios was in control, though it was better to leave it in and have an easy backdoor for when the pebkac.
greetings !
and
switch
Re: (Score:2)
Re: (Score:3)
I don't trust the government to properly fill potholes in the streets let alone have a design review of CPU silicon.
Re:Should the government require audit of designs? (Score:4, Insightful)
riiiight, last I checked the USA government wanted a backdoor in everything because citizens are to be treated like criminals by default.
Re: (Score:2)
riiiight, last I checked the USA government wanted a backdoor in everything because citizens are to be treated like criminals by default.
Citizens are criminals which have not been arrested, charged, or convicted yet.
Re: (Score:2)
These days, the processors come as the actual silicon with firmware (microcode and nanocode) uploaded on power up. These can be changed at any time, so it wouldn;t matter.
This has no name and is not supposed to exist ? (Score:5, Informative)
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.
Re: (Score:1)
This seems pretty heavy stuff. I understand that bad actors could make use of this and there could be lots of conspiracy theories about why its in there, but is this level of control really nessesary for debugging or is it just for convenience or does it look suspicious?
Re: (Score:3, Informative)
It is a much cheaper version of what exists on Intel. But the Intel one requires hardware access, and it is disabled in hardware by grounding the appropriate pins used to access the feature in every non-development motherboard.
Or so it was. It is now possible to access it through USB nowadays (cheaper than wiring a development board), if the vendor screwed it up in the firmware... That said, it is not something a program in the host cpu can access, it *STILL* requires the appropriate hardware. So, it is
Re: (Score:2)
It is a much cheaper version of what exists on Intel. But the Intel one requires hardware access, and it is disabled in hardware by grounding the appropriate pins used to access the feature in every non-development motherboard.
Or so it was. It is now possible to access it through USB nowadays (cheaper than wiring a development board), if the vendor screwed it up in the firmware... That said, it is not something a program in the host cpu can access, it *STILL* requires the appropriate hardware. So, it is not nearly as dangerous as the VIA one.
Mind you, disabling the VIA god mode by default is a three-instruction patch we can add to every OS kernel, now that it is clear there would be a benefit from it. But you can *still* enable it if you get root and that damn /dev/msr security-hole-from-hell-device is present -- but then, we can also patch it to forbid that braindamage. You can always enable it from the kernel/ring 0, but at that point, you no longer need to, anyway.
Are you referring to Intel DCI? That does not require a CCA or anything like that in newer hardware. You just need a motherboard that hasn't used one of the many ways to disable to functionality and a USB 3 A-A cable that does not have the power lines connected. If DCI is disabled in hardware at the End of Manufacturing (like it is supposed to be), then you cannot enable it even with a CCA.
Re: (Score:1)
So then this whole article is BS?
I was wondering why all of the code after the 0x0F, 0x3F was just "bound" statements with arbitrary numbers after them. He wrote the exploit code in this alternate instruction set. Meanwhile the article makes it sound like he spent weeks just fuzzing out the byte sequence "0x0F, 0x3F" and says nothing about how he determined that it needed to be followed by LEA instructions with offsets that were a completely different instruction set. Just imagine how many useless byte s
Re: (Score:2)
Obviously they used this backdoor to retroactively insert documentation of the backdoor after our brave microcode fuzzer discovered it.
Re: (Score:1)
Espousing a 2003 chip to a backdoor now is useless information.
Not really. That was about the point where CPUs became "good enough" for most non-gaming uses. I am typing this on a 2004 vintage CPU (not a Via though), running a 2018 Linux distro, and it's perfectly fine. There are still many CPUs from that era in active use.
Plus, this will let him practice for finding similar issues in more modern CPUs.
Re: (Score:2)
I wonder, (Score:2)
Re: (Score:3)
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 b
you can bet your last dollar (Score:2)
Re: (Score:2)
If you think so you are very religious.
Re: (Score:2)
They all buy the same hardware and network the needed testing?
So a person/ small team working on todays average CPU can have 100, 1000's of networked systems to run the tests on around the world?
Use something like Wake-on-LAN to power the computers getting tested.
Worse than they let on. (Score:4, Insightful)
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.
Re: (Score:2)
Boards with this CPU are almost certainly still out there. They probably are behind firewalls and not directly connected to the Internet so people aren't going to take the threat seriously. But we know that hackers can still sometimes get their fingers into machines on private networks. It will only take the tiniest bit of shell code ran by an innocuous service daemon to crack one of these systems wide open.
Seems like good news to me (Score:2)
Who Done It? (Score:2)
OP trips over back door (Score:2)
Re: (Score:2)
Looks like sloppy editing in the original article?
The demo [purch.com] only shows 2 bytes: 0xF, 0x3F -- as you mentioned.