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.
Their chipsets have always been hot garbage. Their x86 chips are already dog slow, now this? How was VIA even a thing?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
"God bless America"
was invented by false and unknown prophet.
"America must bless Jesus, son of God and Mary"
REMEMBER THE MURDER OF IAN MURDOCK, creator of Debian Linux and leading member of the Free Software community, killed Christmas 2015 by the notoriously corrupt San Francisco police department.
I'll have to look it up but this sounds like news from fifteen years ago, that wasn't really undocumented, but hidden behind some nda's.
oh well. nothing new to see here kids, just the same old backstabbery that is present in humanity, and prevalent in governement, and entertainment systems.
move along home !
passphrase : anymore
Can you play Doom with it? In God mode?
Should the government require a full audit of processor designs to protect itself from backdoors like? Given that processors are showing up as functional elements in practically everything and that it appears that CPU manufacturers do not disclose full functional behaviours should there be a full functional audit, down to looking at chip mask layers of all electronics?
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.
The Via chip is long since departed and exposing any backdoor now on a 18 year old chip seems a waste of time and effort. Mr. Domas if your going to do research do it on something most of us are actually using today. Espousing a 2003 chip to a backdoor now is useless information.
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 hardware works as advertised.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Yes, they should. But NOT dictate design where they can implement their own back door for regional product SKUs. Because, you know those motherfucking super powers will want their own dedicated CPU mask!
so all this time they been backdooring everything FUCK the chip makers intel/amd
In what way is ".byte 0x0f, 0x3f" different in Linux? And what does this instruction do differently in Windows?
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.
, whether my IDT WInChip 2 is also affected: https://www.youtube.com/watch?... .o?
that they can do that with EVERY CPU built, even modern ones out there today in new desktops & laptops, and tablets & smartphones, they obviously have their own key to open root but its still there waiting for the right person to open, people like the NSA and various other high level government goons and spooks, and corporate top dawgs too
Politics is Treachery, Religion is Brainwashing
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.
Every contract that I've signed with Fortune 50 customers includes a no-back-doors clause.
Basically, if you have a back door, it must be
a) documented fully
b) able to be disabled, completely
Seems more than a few companies probably have standing to sue.
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 know whether there's some bug in the outer layers. But just throwing random noise at a system in hopes of hitting a bug is akin to throwing it at a text editor in hopes of getting Shakespeare, or a vaild authentication certificate.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
My impression is that the security community is scraping the bottom of the barrel if an obscure old chip from a minor bit player is the biggest hypestorm on the horizon.
Greed is the root of all evil.
"The command -- ".byte 0x0f, 0x3f" in Linux takes you from the outermost to the innermost ring in four bytes."
What are the other two bytes?
God mode in all Intel CPUs. Sweet.
I thought it was iddqd!
So what? It's Linux, no one cares.
Is there any entity other than government who had the power to create this vulnerability and also keep it secret for a long time? This back door could not be accidental.
Doesn't every chip have one. Kudos to the researcher, but he found last year's NSA hack.