Submitted by 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, security researcher Christopher Domas told the Black Hat conference here Thursday (Aug. 9).
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.
That’s one hell of a bug.
This is a bug in Via chips from 2003.
A patented “bug” that is can disabled, yet that offers kind of “feature” that is far beyond the controversies Intel’s ProcessorID brought to light while it can also be disabled as well.
I just think the extend of VIA’s “bug” is bugging me as much, if no more than Intel’s IME. I mean, what’s next we haven’t yet heard of ? There’s kind of “surprises” I’m not fond of.
Reasons:
1) Juiced Benchmarks to increase it’s performance score?
2) A large client with a special project to run on the chips?
More importantly what’s in the new instruction set, and how much additional performance did it deliver?
With what we now know about governments & their clandestine usage of technology, this may not actually be a bug. I wouldn’t be the least bit surprised if this was something that various world governments asked for. It’s not as if we’ll ever really know for sure…
*Edited for typo*
Edited 2018-08-11 16:57 UTC
It’s a documented instruction for entering a debugging mode.
And there’s a documented way to turn off this functionality.
Literally a documented feature, even down to being in patents and probably developer documentation.
The bug is that it was left on in production environments/firmware (the fault of BIOs devlopers?).
Maybe it was intentionally left on for computers specifically designed for embedded systems. In that case it’d be like someone discovering you can’t lock the doors on a motorbike.
– Brendan
To think that remote code execution isn’t possible on embedded systems is false.
I’m just as quick to blame incompetence and not taking security seriously as I am to blame any other intent, though.
According to the VIA C3 Nehemiah Processor Datasheet September 29, 2004, this is the AltInst, or “Alternate Instruction Execution” opcode “0x0f3f”.
http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemi… (Page A-10).
I suppose announcing “I found “A hidden God Mode!!!” sounds way better than, “I was reading this old datasheet…”
Or, to give some benefit of the doubt, Christopher Domas may have legitimately discovered this through hard work and experimentation– but I found the documentation for the opcode in less time than it took him to show his first slide, so he still fails in the research department.
If every announcement is made with maximum hyperbole, no one is going to take ANY security announcement seriously.
Still, leaving that can of worms at developers’ discretion using just one “documented” bit is criminal. They can pretend all they want it was for “debugging” purpose, but debugging what ? An alternative instruction set found nowhere else than the C3 processor ? How are the other x86 processors dealing with debugging in the first place ? Why allowing “god mode” with global privileged accesses ? At least, why not securing the thing with a challenge key, considering it was intentional ?
Kochise,
This is what I was thinking as well. Whether it’s a bug or intentional doesn’t make it any less alarming as to the consequences to CPU security. Whether this was supposed to be a backdoor or debugging feature really depends the motives of those who created it, which we are not privy to, but is otherwise irrelevant since security is broken regardless.
It seems there may have been a way to disable it, which is good, but that it was not sufficiently documented is very, very, bad. The onus is on the chip maker to clearly document this function and make all users aware of it. Even if this was intended to be a debugging function, it’s no less irresponsible of them for failing to document it properly so that users would know the security implications and lock down procedures.
This type of negligence puts us all at risk and with this in mind I call on all chip makers to publish information about similar backdoor functions existing in CPUs today.
Edited 2018-08-12 14:26 UTC
Like the negligence of Intel making a load of the SS register disable interrupt processing for the following instruction?
Which have been in the x86 family since the 8086 in 1979 and have been documented by Intel, AMD, Cyrix and all other x86 manufacturers?
The blame is all on those that don’t do their job in reading documentation and understanding it.
—
I wonder how high you would scream when realizing booting a modern processor requires correctly setting a myriad option bits correctly, all documented of course…
Megol,
Well, that’s a bit tangential to our discussion on proprietary CPU extensions. My opinion is that even proprietary CPU extensions ought to respect CPU privilege modes. Allowing unprivileged processes to execute privileged undocumented instructions breaks the security model that engineers are accustomed to. Security by obscurity is not a good compromise either. Did Via have a good reason to create undocumented CPU instructions that grant backdoor access by allowing normal user processes to violate ordinary security restrictions? It’s hard to say since none of it is documented…we can only hypothesize.
But one thing is clear: the fact that these VIA systems are vulnerable suggests the risks and/or best practices were not sufficiently understood or communicated by engineers at the time. Rather than argue over the past, I suppose it’s probably more productive for us to use this as a lesson for the future so that it doesn’t happen again.
Edited 2018-08-13 04:10 UTC
I’d add the fact that the need for adding a whole new instruction set alongside with the regular x86 is questionable. Not only considering the cost of transistor implementation, but why should we need an obscure RISC ISA in a x86 chip ?
So it can Get The Facts?
So, setting the bit to ENABLE this alternative instruction mode is a privileged instruction, it had to be enabled by the BIOS or kernel in order to be enabled, right? So… that raises the question, who enabled it?
The bug is not that it was unheard of (as you said, it’s well-documented), the bug is that it was left enabled in production environments.
Special application usage.
Additional registers can significantly speed up more complex algorithms.
I’d look for a special customer who paid for these features.
Or, VIA itself, putting up a hot version for it’s own internal use.
Just like BitCoin mining today.
It could have just been a “back door” that was used while in development and just never taken out … or just forgotten about.
There is some elegance with just the 4 bytes taking you to ring 0.
It reminds me the bug in the early version of Android (G1 era) – all you typed with the hardware keyboard went into the hidden, root-privileged terminal. You typed reboot and oops the phone would reboot.
A bug I’m sure the NSA has known about
this guy finds grave x86 bugs almost year by year. it’s worth checking out his prior presentations on those topics.
He also made the infamous mov obfuscator.
To tell the truth, I think “God mode” sounds somewhat positive. Any LARPers here?
The article ringed a bell. Where I’ve seen this kind of stuff before? Right on the earlier Black Hat videos made by the same guy Chistopher Domas:
BlackHat 2015: https://www.youtube.com/watch?v=lR0nh-TdpVg
blackHat 2017: https://www.youtube.com/watch?v=KrksBdWcZgQ
The first one also discusses the security levels Ring -1 and -2 that the author managed to reach.
So I would not be surprised that there would be others. The x86 chip is actually a computer in itself that has an input (instruction code read from the memory) and an output (either data or behavior). The supported commands list is full of holes and gaps and what is behind those, only manufacturers know.
It is perhaps the time to not trust the CPU just blindly. However we lack the alternatives and have to stick into the computers the stuff that comes out of the factory.
Edited 2018-08-13 11:17 UTC
I’m going to assume this is the amazing undocumented opcode that he discovered and mentioned in his talk blackhat talk some time ago, but which hadn’t gone through the disclosure period yet. It’s cool to finally hear what it is!