TLDR; There is a remote control mechanism in hardware that cannot be fully disabled and you cannot get Intel hardware without it. So while this patch may fix the current vulnerability this situation points to the urgent need for hardware diversity.
Monday SemiAccurate brought you news of a critical remote exploit in all 2008+ Intel CPU’s. Today we will walk you through a chain of thought based on further investigation on how it could be exploited.
Confidence Levels:
While this is only analysis we will note that we believe this is in the wild right now. We would like to make very clear that none of the information here has been publicly proven. However, follow us on an excursion and let us know if you come to a different conclusion. Or if you have other enlightening information, please send it our way.
Hardware and Fuses:
First off all non-server, including workstation but possibly not Atom based, systems contain the hardware needed for this exploit. Over the past several years during conversations with Intel personnel, the hardware is said to be ‘not there’ on machines that don’t have the correct chipset, usually -Q coded variants. Unofficial conversations have led SemiAccurate to believe that the hardware necessary for the AMT exploit is both there and functional. For the short and mid-term past, there is only one chipset die across all ‘small’ (non-E/EP/EX) CPU platforms.
Intel claims the ME is ‘fused off’ completely. SemiAccurate does not believe this to be totally accurate. Our research indicates that there were fuses blown but they don’t actually disable the hardware. If Intel’s claims are accurate then why are bits of functionality that should be “hard disabled” present in other consumer grade features? They may not be robust or fully featured but that is a firmware/software issue. The sizes of the latest branch of ME firmware are ~1.5MB for consumer and ~5MB for corporate.
Blowing Up:
So if the hardware isn’t ‘hard off’, what is it? SemiAccurate supposes the fuses are used to indicate what the system should be allowed to do, not what it is actually physically capable of doing. This is similar to what many chipmakers do for CPUs. A 1S Xeon and a consumer CPU can be the same die, one has fuses blown that make it a Xeon, the other becomes an i5 for example. The software and drivers see them as different (based upon fuses) so you can’t install ‘professional’ drivers on an i5 and consumer drivers don’t pass muster on a Xeon. Nvidia does the same with Tesla and GeForce GPUs, same die but different fuses. AMD does the same as well with Radeon and Firepro. While this doesn’t preclude actual board or packaging changes, the silicon is common except a few fuses.
Going back to the ME contained in the Intel chipsets we see a similar situation. If the right fuses are blown it can make the chip appear to be consumer level, corporate level, and likely various sub-sets for features. In short, if SemiAccurate’s information is correct the only difference between the various consumer and corporate hardware is the fuses that the ME firmware and installers makes decisions based on.
Unblowing Up:
Going back to the GPU examples, there have been various ways over the years to ‘unlock’ disabled cores like this one for some AMD GPUs. Similarly there have been tricks over the years to enable consumer to professional ‘unlocks’ on CPUs and GPUs. The majority of these are done through a technique similar to cracking games and software, you find the places where the software checks for the fuses and modify. Since the fuses are almost universally one time programmable, you can’t change them. However, the software can be changed.
If the software sees fuse #3 being blown as ‘consumer hardware’ and not blown as ‘professional hardware’, you modify it so it reads the hardware in the opposite way. You can literally change one value and have the same hardware read “fuse-blown” as ‘professional hardware’ and “fuse-not-blown” as ‘consumer hardware’. While DRM in games and apps are far more sophisticated than this with multiple levels of checks it is possible to modify the software for access. We question whether Intel has bothered to put such multilayered defenses into their firmware updates much less obscure firmware bits for the ME. Since you can find modified system BIOS and ME firmware for Intel hardware, and hacks seem to be quite prevalent, we think the level of protection on ME code is likely quite low to non-existent. It is also fairly well documented, uses commonly available cores (ARC), and runs Java. This is the long way of saying it wouldn’t take much to modify some ME code rather arbitrarily if you wanted to spend the time and effort. Time and effort is key, remember this later.
Another likely path is that the installer, not the firmware itself, does the validity checks. If this is the case, then an attacker can simply install legitimate ME firmware on hardware that it is not intended for. This would violate Intel policy and possibly open up any sophisticated nation/state hackers to some very steep financial penalties or lawsuits from Intel so we doubt this will happen in the wild. Yes that was sarcasm.
Exploited Bits:
Back to the ME and AMT exploit. SemiAccurate has strong reason to believe that there is an active exploit in the wild at the moment and it is a very sophisticated piece of code. Officially Intel says that the exploit is mitigated if AMT is turned off, the software is uninstalled, and several other hurdles are cleared.
These official documents are very vague in the Description: section which lists a very generic and simple explanation of a possible remote hack. Other sources have described the remote version of the exploit as using custom tools to authenticate with privilege and do nefarious things to ME/AMT enabled machines. This strongly suggests that the parties behind the exploit are very sophisticated and skilled in what they do, think nation/state level actors, not bored teenagers. People with time and that can or want to afford the effort.
In the local attack section Intel is equally vague, essentially only verifying that a local attacker could provision AMT, ISM, and SBT, then use the remote exploit. Once again SemiAccurate’s sources are pointing to an incredibly sophisticated and clever hack. It uses phishing emails to deliver malware which provisions AMT on the target system. We realize how complex this is to do and how many levels it entails. This is not trivial by any means, we do not mean for this to sound trivial, but the path is there. You not only have to know your victim but have an exploit for the OS they are running, and have patches for the ME firmware on the system they receive email on. Given a nation/state level actor, this may not be easy but it certainly is quite plausible.
Once this patched ME firmware is installed, SemiAccurate is unaware of any method to detect that your ME code has been modified. If the phishing email leaves traces of itself, drivers, and code on the host system, that would be detectable, but would the firmware itself be flagged by anything? We doubt it. If it drops, downloads, or simply installs legitimate Intel AMT drivers and ME firmware, would those be flagged by antivirus/antimalware tools? We don’t think so, after all they are legitimate files from a legitimate supplier.
Modified firmware itself would not fall into this category but if you only modified a few bits for a fuse check and didn’t change the versions numbers, reporting tools, if they exist, are unlikely to show very much amiss. Then again if a party exploiting this vulnerability is that sophisticated, fooling anything less than a full cryptographic checksum of the installed code should be trivial. Do you checksum your ME firmware on a regular basis?
Holes Aplenty:
SemiAccurate can say with confidence that there is a hole in all Intel platforms from 2008 onwards, Nehalem through Kaby Lake, ME firmware v6.0-11.6. We can also say with confidence that there are both local and remote exploits possible for this vulnerability. Intel admits to all of this but claims that ‘consumer’ hardware and servers are not vulnerable. [ Lenovo’s listing of impacted systems does list a few “servers”. These would typically be considered consumer grade hardware and not based upon a true server chip with attendant features.]
We lean towards believing Intel is accurate on the server claims but we can’t say with authority that they are not vulnerable. Servers tend to use IPMI of which AMT is a superset of so it could go either way. One example of how to do it right is Dell’s excellent DRAC cards which should avoid the issue on their hardware. Since Intel has been a little less than forthcoming on the ME/AMT issue, and security in general, we would urge readers to verify any claim they make. And verify it in detail. However, Intel servers are starting to look like they are in the clear.
Intel also makes the same claim for consumer systems. Based on the fusings this appears to be the case. One look at the sizes of the ME firmware packages makes it clear there is a lot less in the consumer variant than there is in the professional version. The consumer code is about a third of the size of the professional version for those who didn’t check earlier, ~1.5MB vs ~5MB for the pedantic. The consumer firmware package won’t install on any professional hardware and conversely the professional software won’t install on any consumer hardware that SemiAccurate knows of. By Intel’s standards, this means consumer hardware is safe, and on the surface, it is.
Are Consumers Safe?
So back to Monday’s AMT vulnerability. We have Intel saying that servers and consumer systems are not at risk, only corporate SKUs from 2008 onwards with AMT enabled are in danger. This is true. Unless the attacker can modify the ME firmware to run on boards it wasn’t designed to install on. And deliver it via malware in a phishing email. And it goes undetected by the host system. And it can turn on AMT once installed. And the hacker can write their own tools to do things on the system with the tweaked ME firmware.
SemiAccurate is aware that there are a lot of “ifs” in that chain of logic. If any of them are not possible, then consumer hardware is safe. Based on our research over the past few days and much more done on related topics over the past few years, we believe all of the above is well within the means of any smart individual and quite likely for any nation/state actors. Even if the flash size of the consumer SKUs is too small, a bit of custom code could add any feature needed. This isn’t trivial work, but if you can accomplish any of the other steps, custom coding ME firmware is well within reason. Remember Stuxnet?
So that brings us to the several million dollar question, are ‘consumer’ PC’s safe or do they have the same AMT vulnerability? If you play by the rules, use the official tools, firmware, and code available from Intel, the answer is yes. So Intel is right in saying they are unaffected. Do you know any hackers who only play by the rules and use official tools, firmware, and code when plying their trade? If so, rest easy and don’t worry about the AMT vulnerabilities any more. If not, you would need to have a complex chain of “if’s” happen for it to be a problem. What are the odds?
http://semiaccurate.com/2017/05/03/consumer-pcs-safe-intel-meamt-exploit/
