Deliberate hardware backdoor(s) in x86 CPUs. - Page 1
Forum section: electronics / general

author: TerraHertz
author_rank: Super Contributor
timestamp: September 04, 2018, 10:46:51 am
content: GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUsBlack Hat USA 2018 Published on Aug 28, 2018His 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.

author: wilfred
author_rank: Super Contributor
timestamp: September 04, 2018, 12:15:53 pm
content: 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.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: September 04, 2018, 12:39:07 pm
content: The MSR is documented in the datasheet.http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdfon p56QuoteMoral of the story: If you care about different modes of operation.... read the datasheet

author: tooki
author_rank: Super Contributor
timestamp: September 04, 2018, 12:43:59 pm
content: Back door? Yes. Deliberate? Not reeeeaaaallly. Clearly those bits aren’tintendedfor security circumvention. It’s just a side effect, and one that’s fairly easily patched in software, as the presenter explained.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 04, 2018, 02:42:18 pm
content: 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

author: stj
author_rank: Super Contributor
timestamp: September 04, 2018, 03:51:16 pm
content: 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.

author: Monkeh
author_rank: Super Contributor
timestamp: September 04, 2018, 04:13:06 pm
content: Quote from: T3sl4co1l on September 04, 2018, 02:42:18 pmThe 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.

author: David Hess
author_rank: Super Contributor
timestamp: September 04, 2018, 04:24:31 pm
content: In a production system the BIOS is suppose to disable this special mode. The vulnerable systems did not do this.

author: Kleinstein
author_rank: Super Contributor
timestamp: September 04, 2018, 05:17:39 pm
content: Quote from: T3sl4co1l on September 04, 2018, 02:42:18 pmThey 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.

author: tooki
author_rank: Super Contributor
timestamp: September 05, 2018, 10:40:25 am
content: Quote from: T3sl4co1l on September 04, 2018, 02:42:18 pmNo, it says “not documentedfor 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 watchbeforemaking comments) explained how to patch the OS.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 05, 2018, 06:20:31 pm
content: 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

author: coppercone2
author_rank: Super Contributor
timestamp: September 05, 2018, 07:17:12 pm
content: how do you check? I can't watch that video its too boring

author: Mr. Scram
author_rank: Super Contributor
timestamp: September 05, 2018, 08:21:07 pm
content: Quote from: coppercone2 on September 05, 2018, 07:17:12 pmIn that case, don't worry about it.

author: bitseeker
author_rank: Super Contributor
timestamp: September 05, 2018, 09:24:56 pm
content: 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.

author: coppercone2
author_rank: Super Contributor
timestamp: September 05, 2018, 09:35:49 pm
content: Quote from: Mr. Scram on September 05, 2018, 08:21:07 pmI am sure its some kind of simple script though

author: Mr. Scram
author_rank: Super Contributor
timestamp: September 05, 2018, 10:09:17 pm
content: Quote from: coppercone2 on September 05, 2018, 09:35:49 pmEither watch the video or don't worry about it.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 05, 2018, 10:45:38 pm
content: Quote from: coppercone2 on September 05, 2018, 07:17:12 pmHi coppercone,If you have Debian Linux (Ubuntu, Kubuntu, Mint, Debian, etc...), run the following commands:Code:sudo modprobe msrsudo hd -n 4 -s 0x1107 /dev/cpu/0/msrEssentially, 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

author: coppercone2
author_rank: Super Contributor
timestamp: September 05, 2018, 10:53:04 pm
content: Quote from: Mr. Scram on September 05, 2018, 10:09:17 pmI am not watching a 60 minute video to learn how to try to access one instruction.Thank you Samuel.

author: Mr. Scram
author_rank: Super Contributor
timestamp: September 05, 2018, 11:50:53 pm
content: Quote from: coppercone2 on September 05, 2018, 10:53:04 pmI 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.

author: TerraHertz
author_rank: Super Contributor
timestamp: September 06, 2018, 12:02:50 am
content: 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.

author: coppercone2
author_rank: Super Contributor
timestamp: September 06, 2018, 01:01:27 am
content: Quote from: Mr. Scram on September 05, 2018, 11:50:53 pmYea because your a forum cop that knows what I am occupied with

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 06, 2018, 01:29:54 am
content: 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

author: Mr. Scram
author_rank: Super Contributor
timestamp: September 06, 2018, 01:37:11 am
content: Quote from: coppercone2 on September 06, 2018, 01:01:27 amAn 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.

author: Monkeh
author_rank: Super Contributor
timestamp: September 06, 2018, 01:54:48 am
content: Quote from: TerraHertz on September 06, 2018, 12:02:50 amIt 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.

author: coppercone2
author_rank: Super Contributor
timestamp: September 06, 2018, 02:04:58 am
content: 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.

author: coppercone2
author_rank: Super Contributor
timestamp: September 06, 2018, 02:16:17 am
content: Quote from: TerraHertz on September 06, 2018, 12:02:50 amIt's a guy talking about assembly programming man, for an hour, I want to throw darts at the monitor

author: tooki
author_rank: Super Contributor
timestamp: September 06, 2018, 03:51:23 am
content: Quote from: bloguetronica on September 05, 2018, 06:20:31 pmDo you have the exact same CPU as in the video? If not, then the same bit doesn’t mean the same thing, and you do not have the “god bit” on.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 06, 2018, 03:52:21 am
content: Quote from: TerraHertz on September 06, 2018, 12:02:50 amI would bet on that if that bit is actually applicable, and settable, and hence has the desired effect on any given x86 processor. You can actually edit any register in memory, either on Windows or Linux. And it is possible to lock and unlock hardware features that way.Quote from: coppercone2 on September 06, 2018, 02:04:58 amSometimes this issues can escape and only be discovered too late, after many chips have been produced. Any mistake or logic error on the state machine, for instance, and that's it. Some companies may opt to shush about it, so the bug won't be discovered outside. But sooner, or later, it is.In the past years I've discovered a big flaw in the CP2130, that Silicon Devices already knew but they didn't released any note or errata up to this day). Basically, this USB to SPI bridge has a race condition that is triggered when you try to change or disable the chip select immediately after a short (few bytes) bulk transfer of data. Basically, after one or a few errors, the chip would get unresponsive with its SPI ACT pin permanently toggling. This race condition is also triggered by changing the state of a GPIO pin immediately after such data transfer.Long story short, I would get such errors very frequently when controlling the hardware via libusb on my real Linux machine. I would have less frequent errors when using one of my VMs, still using libusb under Linux. On my Windows XP VM, using the Silicon Labs software, I wouldn't have such snags. I tried reproducing the errors on another machine, a Chip computer (the nine dollar computer) and the errors were rare. Still Linux and still libusb.I assumed that this had to do with libusb itself, but I questioned why the error was harder to reproduce on slower machines. One day, I decided to analyze the USB communication to the problematic device, and found out that this error happened always after a bulk transfer, when I was either changing or disabled the chip select. After much thought and experimentation, I concluded that adding a wait of 100us between the bulk transfer and every chip select operation would "solve" this.I've confirmed this with the guys from Silicon Labs, and the result is here (second post):https://www.silabs.com/community/interface/forum.topic.html/an792_command_id0x-YWCXConclusion: been scanning for an errata from time to time, but saw none yet. Probably I'll have to alert for this on my blog. This chip is actually pretty good, despite this severe and impairing issue, and it is a shame. I hope I didn't stray to much out of topic, but this only to illustrate how companies prefer to go silent instead of admitting a bug they have within their products, irregardless of that bug being intended or not.Quote from: tooki on September 06, 2018, 03:51:23 amNo, my CPU is different. Yes, there is a chance that this register on my CPU doesn't correspond to that one sough after in the video, and the information I've got may have no meaning.Kind regards, Samuel Lourenço

author: tooki
author_rank: Super Contributor
timestamp: September 06, 2018, 04:07:27 am
content: “A chance”? Let’s try “practically guaranteed” if the CPU is from another manufacturer.

author: David Hess
author_rank: Super Contributor
timestamp: September 06, 2018, 04:30:38 am
content: Quote from: TerraHertz on September 06, 2018, 12:02:50 amI assume that once GOD mode is disabled by the BIOS, it cannot be enabled without a hard reset which would just restart the BIOS so the operating system has no control over it.The mistake was that some BIOSes did not disable GOD mode.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 06, 2018, 04:35:50 am
content: One would hope that once it's reset it can't be set, but the CPU in question was probed successfully in kernel mode, so who knows.Tim

author: stj
author_rank: Super Contributor
timestamp: September 06, 2018, 04:47:05 am
content: Quote from: David Hess on September 06, 2018, 04:30:38 ampointless, it would be simple for mallware to patch the bios, re-flash it and then crash the system for reboot.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 06, 2018, 05:01:35 am
content: Quote from: tooki on September 06, 2018, 04:07:27 amMy CPU is an Intel. Different model, certainly. Usually, most registers will match between Intel CPUs. I can't say it this one corresponds or not.Kind regards, Samuel Lourenço

author: Monkeh
author_rank: Super Contributor
timestamp: September 06, 2018, 01:09:47 pm
content: Quote from: bloguetronica on September 06, 2018, 03:52:21 amNot as a normal, unprivileged task you can't.Quote from: bloguetronica on September 06, 2018, 05:01:35 amThis does not apply to any Intel CPU full stop.Quote from: TerraHertz on September 06, 2018, 12:02:50 amI would be extraordinarily surprised. Please, for the love of logic, take your conspiracy theories elsewhere.Quote from: stj on September 06, 2018, 04:47:05 amAnd why, exactly, would they need to do that when they are already in possession of the necessary privileges to reprogram the BIOS?

author: David Hess
author_rank: Super Contributor
timestamp: September 06, 2018, 02:10:23 pm
content: Quote from: stj on September 06, 2018, 04:47:05 amIf the malware has enough control of the system to reflash the BIOS, then the system is already compromised.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 06, 2018, 02:23:48 pm
content: Quote from: Monkeh on September 06, 2018, 01:09:47 pmMake no mistakes. Although in Linux you'll need root permissions, in Windows you can do it simply with "RW Everything" as long as you are logged in as an administrator, which is actually very normal in Windows. RW Everything is just an example on an application that can access almost every register. In fact, you are able to enable features as power states via this program, among other things. You don't need to access the BIOS.As for the CPU, I now noticed that this bug refers to the VIA C3. My mistake!Kind regards, Samuel Lourenço

author: Monkeh
author_rank: Super Contributor
timestamp: September 06, 2018, 02:38:56 pm
content: Quote from: bloguetronica on September 06, 2018, 02:23:48 pmYou should test your assumption against a modern Windows OS, you are indeed making mistakes.

author: David Hess
author_rank: Super Contributor
timestamp: September 06, 2018, 02:42:24 pm
content: God mode in the VIA processor is like the VM extensions on an Intel processor. Once they are disabled, they cannot be enabled without a complete reset or at least that is how they are suppose to work if the hardware is designed properly. So once the BIOS disables them, the OS and any other code cannot use or enable them.If some application manages to rewrite the BIOS, then enabling God mode after the next reset is the least of the problems. The application could also write newSMM (system management mode)code into the BIOS and gain access to the entire system that way.

author: tooki
author_rank: Super Contributor
timestamp: September 06, 2018, 04:09:06 pm
content: Quote from: bloguetronica on September 06, 2018, 02:23:48 pmNo kidding… it's not like watching the video is important or anything…Quote from: bloguetronica on September 06, 2018, 05:01:35 amObviously, the registers defined in the CPU architecture (i.e. the standard) must be consistent (at least with names, not sure about actual addresses). But the ones in question are the MSRs:manufacturer-specific registers. By definition, they are NOT part of the x86/x64 architecture! They don't have names, their addresses are undocumented (publicly), and they're damned well not agreed upon by competing manufacturers!So yeah, an Intel CPU may or may not have an MSR with the same address. But it's not going to be for the same purpose, if it exists at all.

author: tom66
author_rank: Super Contributor
timestamp: September 06, 2018, 05:42:56 pm
content: Quote from: stj on September 06, 2018, 04:47:05 am"simple"How many bloody BIOSes do you think there are STJ, about three?Maybe try 10,000.

author: stj
author_rank: Super Contributor
timestamp: September 06, 2018, 05:50:16 pm
content: you read it from the ram, scan it for the code your looking for, patch the bytes.then write the bulk-erase sequence to the flash registeres and stream the code to them.anybody who has cracked software knows how to scan an unknown block of code for a byte sequence - possibly using hauristics to find code by the area it accesses.

author: bloguetronica
author_rank: Frequent Contributor
timestamp: September 06, 2018, 06:12:44 pm
content: Quote from: Monkeh on September 06, 2018, 02:38:56 pmDid tested them. Mark my words. Of course I didn't wrote MSR specific bits, because I don't know if they are accessible by that tool in the first place. However, I was able to disable USB related features at will. It was an integral part of my job, actually. So, be sure that you can enable and disable hardware features via RW everything. Very low level stuff.Kind regards, Samuel Lourenço

author: Monkeh
author_rank: Super Contributor
timestamp: September 06, 2018, 06:24:13 pm
content: Quote from: stj on September 06, 2018, 05:50:16 pmYou assume many things. That you already have god level access, that the system allows you to read the BIOS from RAM, that the system allows you to write the BIOS to flash, that the code sequence is that easily located and false positives are impossible..

author: free_electron
author_rank: Super Contributor
timestamp: September 06, 2018, 07:06:15 pm
content: These backdoors have existed since the 80386. Flick the thing in debug mode and hook up a trace probe and you can go ANYWHERE in memory space without the processor knowing. how do you think they debug these complex processors during development ? You are supposed to tie the pin hard to ground to block this. Motherboard makers don't do this as they use this mechanism to test the board in circuit. They strap it using a resistor. Overdrive that, and find out the protocol, and you are master of the system.I would not be amazed that there is a sidechannel to access this stuff through software. That intel ME processor (which is an ARC) can do lots of stuff... it even runs a version of minix...Look at how they can perform microcode updates at boot time. The fact that they can alter the instruction set by loading a new binary package into the CPU ... if you figure out how to craft such a package ... you can stick whatever you want in there.i remember reading an article on this debug mechanism that gave access to the on-chip protected cache memory. Someone made a toolkit using a Tyan motherboard, an ISA card and a piece of software to crack copy protections. Whenever a certain trigger occurred the ISA card would flick the pin of the cpu ,effectively halting it. An onboard small processor ( i think it was an 8051) would dump the cache contents , then resume normal operation. The toolkit could then examine the contents of the memory dump. You could alter contents and write back by doing the process in reverse. the ISA card would halt the CPU , sideload the cache and resume operation.Oodles of stuff could be done using this trick.Interesting reading was 'The undocumented PC' by Frank van Gilluwe.

author: GlennSprigg
author_rank: Super Contributor
timestamp: September 07, 2018, 02:16:31 pm
content: In this computer driven world, there are ALWAYS 'backdoors' programmed into things.The 'Bosses' don't even have to know it !!... The 'Coders' know though... :-)They are not always innocuous Fun 'EasterEggs' built into software, like 'Windows'.A modern electronic/digital 'Poker' machine, is just a computer, that's been programmed.Checks are supposed to be in place, but it is not hard for a programmer to 'hide' someinnocent looking code, looking at a complex key-sequence etc. (Saying no more now...).Although seemingly non-criminal in comparison, I KNOW, being from various technicalfields, and having it physically demonstrated to me by 'Lift' technicians, (I will not saywhat company), that they 'program' their lift computers to do what they want, withoutany knowledge of the company/bosses. For instance, in one high-rise building, if youhit a 'certain' button 20 times within 8 seconds, and then hit the 'floor' you want, itcancelled ALL other calls, either direction, and took you to where you want, express...If it's 'computer' controlled, you can do anything behind the scenes !!

author: David Hess
author_rank: Super Contributor
timestamp: September 07, 2018, 06:52:44 pm
content: Quote from: free_electron on September 06, 2018, 07:06:15 pmThey have existed through various interfaces as well. Any bus-master capable interface can potentially access all of memory unless prevented somehow. There have been Firewire exploits that took advantage of this especially on Apple; USB does (or did?) not support bus-master operation so it was immune to this. GPUs can also be used to do this. I assume the various expansion card standards commonly used on laptops like PCMCIA suffered from this.CPUs which include I/O memory management can stop this by preventing bus-masters from accessing arbitrary memory addresses because all I/O accesses to memory have to go through them but as with the Apple example above with Firefire, manufacturers generally do not bother.