Deliberate hardware backdoor(s) in x86 CPUs.

[TerraHertz]

GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs
Black Hat USA 2018  Published on Aug 28, 2018

His method of finding this is awesome.
The implications... urrgh. Oh well, I already knew Wintel machines cannot be trusted.

Interesting that the NSA malware toolkit leaked in 2016 didn't (so far as I know) have any reference to this stuff. Which means it was probably a limited hangout.

SMM, IME (running a modified MINIX OS, always-on, with a TCP/IP stack), and now this.
A kind of system 'bug' that's best fixed with baseball bats.

[wilfred]

It doesn't have anything to do with Windows or Intel. This research was done on a VIA C3 processor.

The video from 6:00- 6:30 is quite interesting.

[NivagSwerdna]

The MSR is documented in the datasheet.

http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf on p56

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.

Moral of the story: If you care about different modes of operation.... read the datasheet

[tooki]

Back door? Yes. Deliberate? Not reeeeaaaallly. Clearly those bits aren’t intended for security circumvention. It’s just a side effect, and one that’s fairly easily patched in software, as the presenter explained.

[T3sl4co1l]

Documented?  The quote specifically says those functions are left undocumented!

Ah, but if they aren't documented, how can one patch their software to ensure it is secure?  Mind that he found machines that started with it enabled!

Tim

[stj]

well the modern intel chipsets all have an mcu running in the background with full access,
so i agree that baseball bats, metal bars or axes are the best solution to this type of "feature"

amd have the capability too, but it's less certain that they are used.
best to play it safe and assume the worst though.

[Monkeh]

Documented?  The quote specifically says those functions are left undocumented!

Ah, but if they aren't documented, how can one patch their software to ensure it is secure?  Mind that he found machines that started with it enabled!

Tim

The entry method is documented - so long as you ensure the instruction is disabled, no foul. As for the ones with this obscure 'feature' enabled on boot, well, someone oopsied. Badly.

[David Hess]

In a production system the BIOS is suppose to disable this special mode.  The vulnerable systems did not do this.

[Kleinstein]

Documented?  The quote specifically says those functions are left undocumented!

Ah, but if they aren't documented, how can one patch their software to ensure it is secure?  Mind that he found machines that started with it enabled!

Tim

They seem to have documentation to those with special needs. So that someone like bios code builder (e.g. at a board manufacturer) can normally disable (or not enable it) the backdoor and normal kernel code should not execute that special unlock instruction.
So for this backdoor one needs the vulnerable processor and boot code (early bios / boot-loader) that as a bug enables the bug. So it is more like a firmware bug in some of the VIA C3 systems.

[tooki]

Documented?  The quote specifically says those functions are left undocumented!

Ah, but if they aren't documented, how can one patch their software to ensure it is secure?  Mind that he found machines that started with it enabled!

Tim

No, it says “not documented for general use”, but that it’s available for those who need it, i.e. chipset or firmware builders, and probably commercial OS builders, too.

Also, the video (which maybe you should watch before making comments) explained how to patch the OS.

[bloguetronica]

Wow! The consequences of this backdoor (intended or not), are very serious. Anti-virus no longer effective? I'll have to learn more about MRS ad see if "God mode" is enabled by default on my system. This is even worse than Meltdown and Spectre.

Edit: Confirmed that I have the "God mode" bit enabled.

Kind regards, Samuel Lourenço

[coppercone2]

how do you check? I can't watch that video its too boring

[Mr. Scram]

how do you check? I can't watch that video its too boring

In that case, don't worry about it.

[bitseeker]

Thanks for the video link. That was super interesting, not only in seeing all the low-level CPU stuff, but also all the software and hardware he built to uncover and decypher the DEC and DEIS. Really neat stuff.

[coppercone2]

how do you check? I can't watch that video its too boring

In that case, don't worry about it.

I am sure its some kind of simple script though

[Mr. Scram]

I am sure its some kind of simple script though

Either watch the video or don't worry about it. 

[bloguetronica]

how do you check? I can't watch that video its too boring

Hi coppercone,

If you have Debian Linux (Ubuntu, Kubuntu, Mint, Debian, etc...), run the following commands:

Code: [Select]

sudo modprobe msr
sudo hd -n 4 -s 0x1107 /dev/cpu/0/msr

Essentially, this is the two commands he ran in the video. About the options used in the "hd" command, according to its man page, the "-n" option defines the number of bytes returned, while "-s" is there to define the offset. The path is self explanatory, as it directs to the MSR (model specific register) of the CPU. I would need to see the databook of this CPU to see the meaning of the register returned.

According to what he says, you have to check the lowest bit of the first (lowest) byte in the sequence of four pairs of hexadecimal digits that appears after running "hd". Check the first line, next to the starting address. If the bit is "0", you should be fine. If the first is "1" (in other words, the value of that byte is not an even number, or more explicitly does not end in "0", "2", "4", "6", "8", "A", "C", "E"), you have the bit enabled.

P.S.: I was wrong. I was interpreting the "0000110b" as being the symptom, but that is just the end address. The man page of "hd" sure supplies plenty of information. Duh!

Kind regards, Samuel Lourenço

[coppercone2]

I am sure its some kind of simple script though

Either watch the video or don't worry about it. 

I am not watching a 60 minute video to learn how to try to access one instruction.

Thank you Samuel.

[Mr. Scram]

I am not watching a 60 minute video to learn how to try to access one instruction.

Thank you Samuel.

I was trying to provoke you into doing some basic research. If you had simply Google searched the subject you would have found information that would have told you the problem is unlikely to apply to your hardware at all, as this concerns relatively obscure processors. You would have had your answer a lot quicker than you have gotten it now, with less effort.

The tendency of not wanting to do the work has been visible in other threads too. People here can offer amazing insights, but usually on the premise that you put in the effort yourself too.

[TerraHertz]

This one is going to be fascinating to watch. One aspect will be the fallout as everyone with any interest in computer security uses the tools now available, to probe for deeply embedded RISC backdoor engines in their own x86 machines.

Another aspect is the interesting spread of reactions, among those who hear of it. "Too boring" and "it's not relevant to me" forms of denial even here in a tech-forum...

He's shown an absolutely indisputable total circumvention of ALL security protections, deliberately and secretly built into the processor core of at least one x86 CPU. And released the tools for others to investigate/exploit the hole in any x86 system.

Whether this exists in most or all recent/current x86 variants, remains to be proven. (But now soon will be, given the tools released.)
I'm guessing it will turn out to be all of them, and 'parties who need this feature and were given the details' will include the three letter agencies. I wonder if this is documented in the Intel Gray Books, or if it's even more secret than those?

Another detail to be determined - everyone is assuming the 'god mode bit' is only set or cleared by BIOS at startup. I'd lay a bet it turns out that Windows has a 'hidden feature' to enable it in response to some innocent-looking external communication event.
I'd also not be surprised if 'GOD remote enable' turns out to have been slipped into Linux somewhere as well.
Or BIOSs always turning it on if the OS being booted is Linux.

[coppercone2]

I am not watching a 60 minute video to learn how to try to access one instruction.

Thank you Samuel.

I was trying to provoke you into doing some basic research. If you had simply Google searched the subject you would have found information that would have told you the problem is unlikely to apply to your hardware at all, as this concerns relatively obscure processors. You would have had your answer a lot quicker than you have gotten it now, with less effort.

The tendency of not wanting to do the work has been visible in other threads too. People here can offer amazing insights, but usually on the premise that you put in the effort yourself too.

Yea because your a forum cop that knows what I am occupied with

[T3sl4co1l]

Would be pretty easy to scan for files that contain a standard unlock sequence I suppose, assuming they're in the clear, not encrypted.  TLAs would tend to obfuscate something so simple, but others may not.

Tim

[Mr. Scram]

Yea because your a forum cop that knows what I am occupied with

An attitude won't get you far on these forums. Please just do some research and you'll find people more than happy to help you with remaining questions. That's all. 

[Monkeh]

He's shown an absolutely indisputable total circumvention of ALL security protections, deliberately and secretly built into the processor core of at least one x86 CPU.

It is nothing of the sort - the existence and entry method are documented. And it's not specifically designed as a security circumvention, no matter how much you want it to be.

[coppercone2]

The argument may be that they did not realize the gravity of this issue or did not devote time to explaining it.

Think about product datasheets for certain electronics chips, the engineers are often expected to put notes of interest there, so that less experienced designers may be able to make a more robust design.

Based on what I see I would attribute the problem to the document creator and editors not giving a shit or misunderstanding his customers thought process and skill level towards implementation.

For instance, an excellent datasheet/applications editor Jim Williams is diligent to warn. Despite the fact that they are selling to engineers, and the purpose of the document is to mainly explain electrical physics behavior, his application notes on high voltage have numerous warnings on how to safely use high voltage, high voltage areas of his test circuit are highlighted.. this is because he is a good engineer and he mingled with other people so he knows that many of the designers are not knowledgeable about HV and that its not really covered well in school. He had no obligation to include the amount of details he did, but he wanted to be complete and do a good job so the documentation is high quality. Same thing about signal quality considerations during measurement. Notice how better data sheets tell you the trials and tribulations the engineers went through to implement the circuits, vs the flybynightlowbudgetdatasheets that are about 1/5th the size and expect you have a arsenal of PHD's to design?

Maybe I am trying to say that he was aware of the industry norm during his writings or that he was able to 'read a crowd'. All sorts of things go into this, such as industry momentum, the mean product design time and of course the expected experience level of manufactures that use the chip. Look how successful ADAFRUIT is despite being a reseller.