Remote security exploit in all 2008+ Intel platforms
Как раз к одному обсуждению недавнему :) 
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
(Обращаю внимание на "Intel would like to thank Maksim Malyutin from Embedi for reporting this issue and working with us on coordinated disclosure.", все эти бла-бла-пугалки-страшилки от SemiAccurate в помойку)
Добавлено:
* http://io.netgarage.org/me/
* http://me.bios.io/images/0/0f/Csk_lacon12_intel_amt.pdf
* http://people.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-Vassilios_Ververis-with-cover.pdf
* https://github.com/LongSoft/UEFITool/releases (посмотреть свой .CAP-файл BIOS'а в поисках ME/AMT и проч.)
Добавлено #2 (детали):
* https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
* https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability
* https://www.theregister.co.uk/2017/05/05/intel_amt_remote_exploit/
Добавлено #3 (еще детали; "exploit"):
* https://www.embedi.com/news/mythbusters-cve-2017-5689
* https://www.tenable.com/blog/intel-amt-vulnerability-detection-with-nessus-and-pvs-intel-sa-00075
Updated 2x: Nehalem through Kaby all remotely and locally hackable
Every Intel platform from Nehalem to Kaby Lake has a remotely exploitable security hole. SemiAccurate has been begging Intel to fix this issue for literally years and it looks like they finally listened.
Updated May 1, 2017 @ 3:35pm: Intel just confirmed it, but not to SemiAccurate. You can read their advisory here.
Updated May 2, 2017 @ 7:40pm: Lenovo has a page up with affected systems and fix ETAs. It includes some ‘consumer’ products as well as ‘servers’.
The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware. If this isn’t scary enough news, even if your machine doesn’t have SMT, ISM, or SBT provisioned, it is still vulnerable, just not over the network. For the moment. From what SemiAccurate gathers, there is literally no Intel box made in the last 9+ years that isn’t at risk. This is somewhere between nightmarish and apocalyptic.
First a little bit of background. SemiAccurate has known about this vulnerability for literally years now, it came up in research we were doing on hardware backdoors over five years ago. What we found was scary on a level that literally kept us up at night. For obvious reasons we couldn’t publish what we found out but we took every opportunity to beg anyone who could even tangentially influence the right people to do something about this security problem. SemiAccurate explained the problem to literally dozens of “right people” to seemingly no avail. We also strongly hinted that it existed at every chance we had.
Various Intel representatives over the years took my words seriously, told me I was crazy, denied that the problem could exist, and even gave SemiAccurate rather farcical technical reasons why their position wasn’t wrong. Or dangerous. In return we smiled politely, argued technically, and sometimes, usually actually, were not so polite about our viewpoint. Unfortunately it all seems to have been for naught.
The problem is quite simple, the ME controls the network ports and has DMA access to the system. It can arbitrarily read and write to any memory or storage on the system, can bypass disk encryption once it is unlocked (and possibly if it has not, SemiAccurate hasn’t been able to 100% verify this capability yet), read and write to the screen, and do all of this completely unlogged. Due to the network access abilities, it can also send whatever it finds out to wherever it wants, encrypted or not.
While these capabilities sounds crazy to put on a PC, they are there for very legitimate reasons. If an IT organization needs to re-image a system, you need to be able to remotely write to disk. Virus cleaning? Scan and write arbitrary bits. User logging and (legitimate) corporate snooping? That too. In short everything you need to manage a box can be exploited in ugly ways. When Intel told us that a version of AMT could be used to bare metal image a dead machine over a cellular connection, we turned white. We explained to them why SemiAccurate thought this was a bad idea and they respectfully disagreed. I’ll bet they aren’t laughing now.
The news today is more problematic than it seems though, the nuances of security disclosures tend to be lost on those not involved in the field. What we mean by this is if a company knows about a flaw and doesn’t fix it for quite literally years, there usually is a reason why. For a security hole that was present for about a decade that suddenly gets patched, this means an affected party with the leverage to get Intel to act did just that. Again.
We are cheering that the hole is being fixed and Intel is issuing a patch. That and Intel has plans on when to issue “reactive” NDAs to customers several weeks before the “proactive” and “public” disclosures. [Editor’s emphasis] That begs the question of reacting to what? If it isn’t being exploited, there is nothing to react to before it is disclosed, right?
Back to the point, what is the issue? Again we won’t be specific until the fixes are out but on April 25, Intel released a firmware fix for this unnamed issue. It affects every Intel machine from Nehalem in 2008 to Kaby Lake in 2017. The vulnerability affects AMT, ISM, and SBT bearing machines. For those not up on Intel security acronyms, this is every Intel box shipped with an Intel chipset for the past decade or so.
Depending on whether you are a glass half empty or half full type, there is a bit of good news. This flaw is remotely exploitable only if you have AMT turned on, that is the ‘good’ news. The bad news is that if you don’t have it turned on or provisioned the vulnerability is still exploitable locally. If you aren’t the half full type, you might sum this up by saying there is no way to protect a manageable Intel based computer until this hole has been patched, it is that bad. Let me repeat, you can not protect a manageable PC or server with this flaw until there is a patch, period. This flaw is present in ME firmware from version 6.0-11.6, things before and after those numbers are not affected probably because they used the AMT engine with the non-ARC CPU cores in older iterations.
Luckily Intel has some mitigation options for the affected users, that is you, whether you know it or not. They have two fixes for provisioned AMT and non-provisioned boxes, both prevent the issue from happening until the firmware update has been distributed by OEMs. Unfortunately since this issue is not disclosed officially yet, they won’t tell you what it is. Due to the severity of the issue, we highly recommend you make these changes immediately, don’t wait for the official disclosure.
If you have provisioned AMT or ISM on your systems, you should disable it in the Intel MEBx. If you haven’t provisioned these, or have and want to mitigate the local vulnerability too, there are more steps to take. If you have a box with AMT, ISM, or SBT, you need to disable or uninstall Local Manageability Service (LMS) on your boxes. Intel helpfully points out that doing this will mean your box can’t be managed using those services when you disable them. If this makes you think about whether or not to disable those things, trust us, don’t think about it, disable them NOW.
This brings us to a very ugly point. Intel has put AMT and it’s variants into every device they make. Some you can’t see because it is fused off but off is a very strong term. There are several features that AMT provides that are present in consumer systems even though the ‘technology’ isn’t there. This is one of the arguments that SemiAccurate has had with Intel security personnel over the years, we have begged them to offer a SKU without the AMT hardware for just this very reason. Intel didn’t, the pressure to lock corporate customers in to their silicon was too high.
With this exploit, every Intel box for 9+ years is now vulnerable because you couldn’t buy a box without it even if you wanted to other than a few older 4S servers. If you deployed Intel’s management solutions like AMT or SBS, you know the ones we mocked, you now have to turn it off or face remote exploitation. If you are a large corporation with AMT deployed, and most companies have deployed it, turning it off is easy, just a console command or three and it is done. Turning it back on however means going to every desktop, laptop, and server in your organization manually patching the BIOS and ME firmware, then turning the ME features like AMT back on. Manually.
This all assumes that there is a patch for your machine. Intel has a slew of BIOS/ME firmware patches out and in the hands of OEMs now. From here it isn’t Intel’s problem, and we mean that without even a hint of sarcasm. Intel has done their part and delivered the updated firmware to OEMs, it is now up to them to do the right thing. Some will.
The problem from here is twofold starting with no-name PCs. If you have a white-box PC or one from a sketchy vendor, chances are they won’t bother with a firmware update. Security is a cost center and most OEMs run on margins too thin to bother with security patches even if they cared. Most simply don’t care.
On the other hand OEMs who do actually care, that would be most of the big ones like Dell, HP, Lenovo, and so on, will put out patches for their machines. The second problem is for how long? No not for how long will they keep patches up but how far back will they issue the patches for? Most OEMs don’t patch things out of warranty for good reason, this is a fair thing for them to do. Most PCs have a one or three year warranty with five being the rare exception for some boxes like servers. Most of the PCs in this category from tier 1 and 2 vendors should have patches issued in short order. Check for them daily and apply them immediately, really.
At best though this means there will be patches out for less than half of the affected machines. Do you or your organization have any machines in service but out of warranty? I’ll bet you do. What about embedded devices that are increasingly PC based? Digital signage perhaps? Industrial controls. HVAC. Security systems. Flight controls. Air traffic controls. Medical devices. I could go on but all of these are likely PC based and anything infrastructure related is likely networked, management engine enabled, and quite possibly in warranty from the service provider. But quite likely out of warranty from the board vendor who made the underlying PC the service it is based on. Do you know what is in your systems? I’ll bet you think you do.
So this Intel AMT/ISM/SBT vulnerability is the proverbial ‘big one’. It is remotely exploitable if you have Intel’s management solutions in use, locally exploitable if you have them provisioned in your machine. You have them on your machine. You really need to turn them off, uninstall all the pieces, and do it now, don’t wait for the official word on WW26. That is the end of June for non-Intelspeak people, they will officially issue this guidance then along with OEM disclosures.
Because SemiAccurate strongly suspects this vulnerability is being exploited in the wild as we speak, you should take the official mitigation steps as soon as possible. Then contact your OEMs and strongly suggest that firmware patches for every system, including-out-of warranty systems, would be appreciated by you. Then go over every embedded Intel board with a fine tooth comb. Remember it is every Intel system from Nehalem in 2008 to Kaby Lake in 2017, ME firmware version from 6.0-11.6. If you have or suspect you have these, act now. Really. This is the big one but you can take some corrective action before it is too late. Richard Stallman was right about firmware, and there are alternatives now too.
TLDR; Average computer user - If your system is 10 years old or newer it is likely exploitable, check for patches daily and install all patches immediately. If there is no patch, back up data and replace.
https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
Are consumer PCs safe from the Intel ME/AMT exploit?
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.
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?
https://semiaccurate.com/2017/05/03/consumer-pcs-safe-intel-meamt-exploit/
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
(Обращаю внимание на "Intel would like to thank Maksim Malyutin from Embedi for reporting this issue and working with us on coordinated disclosure.", все эти бла-бла-пугалки-страшилки от SemiAccurate в помойку)
Добавлено:
* http://io.netgarage.org/me/
* http://me.bios.io/images/0/0f/Csk_lacon12_intel_amt.pdf
* http://people.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-Vassilios_Ververis-with-cover.pdf
* https://github.com/LongSoft/UEFITool/releases (посмотреть свой .CAP-файл BIOS'а в поисках ME/AMT и проч.)
Добавлено #2 (детали):
* https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
* https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability
* https://www.theregister.co.uk/2017/05/05/intel_amt_remote_exploit/
Добавлено #3 (еще детали; "exploit"):
* https://www.embedi.com/news/mythbusters-cve-2017-5689
* https://www.tenable.com/blog/intel-amt-vulnerability-detection-with-nessus-and-pvs-intel-sa-00075
Updated 2x: Nehalem through Kaby all remotely and locally hackable
Every Intel platform from Nehalem to Kaby Lake has a remotely exploitable security hole. SemiAccurate has been begging Intel to fix this issue for literally years and it looks like they finally listened.
Updated May 1, 2017 @ 3:35pm: Intel just confirmed it, but not to SemiAccurate. You can read their advisory here.
Updated May 2, 2017 @ 7:40pm: Lenovo has a page up with affected systems and fix ETAs. It includes some ‘consumer’ products as well as ‘servers’.
The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware. If this isn’t scary enough news, even if your machine doesn’t have SMT, ISM, or SBT provisioned, it is still vulnerable, just not over the network. For the moment. From what SemiAccurate gathers, there is literally no Intel box made in the last 9+ years that isn’t at risk. This is somewhere between nightmarish and apocalyptic.
First a little bit of background. SemiAccurate has known about this vulnerability for literally years now, it came up in research we were doing on hardware backdoors over five years ago. What we found was scary on a level that literally kept us up at night. For obvious reasons we couldn’t publish what we found out but we took every opportunity to beg anyone who could even tangentially influence the right people to do something about this security problem. SemiAccurate explained the problem to literally dozens of “right people” to seemingly no avail. We also strongly hinted that it existed at every chance we had.
Various Intel representatives over the years took my words seriously, told me I was crazy, denied that the problem could exist, and even gave SemiAccurate rather farcical technical reasons why their position wasn’t wrong. Or dangerous. In return we smiled politely, argued technically, and sometimes, usually actually, were not so polite about our viewpoint. Unfortunately it all seems to have been for naught.
The problem is quite simple, the ME controls the network ports and has DMA access to the system. It can arbitrarily read and write to any memory or storage on the system, can bypass disk encryption once it is unlocked (and possibly if it has not, SemiAccurate hasn’t been able to 100% verify this capability yet), read and write to the screen, and do all of this completely unlogged. Due to the network access abilities, it can also send whatever it finds out to wherever it wants, encrypted or not.
While these capabilities sounds crazy to put on a PC, they are there for very legitimate reasons. If an IT organization needs to re-image a system, you need to be able to remotely write to disk. Virus cleaning? Scan and write arbitrary bits. User logging and (legitimate) corporate snooping? That too. In short everything you need to manage a box can be exploited in ugly ways. When Intel told us that a version of AMT could be used to bare metal image a dead machine over a cellular connection, we turned white. We explained to them why SemiAccurate thought this was a bad idea and they respectfully disagreed. I’ll bet they aren’t laughing now.
The news today is more problematic than it seems though, the nuances of security disclosures tend to be lost on those not involved in the field. What we mean by this is if a company knows about a flaw and doesn’t fix it for quite literally years, there usually is a reason why. For a security hole that was present for about a decade that suddenly gets patched, this means an affected party with the leverage to get Intel to act did just that. Again.
We are cheering that the hole is being fixed and Intel is issuing a patch. That and Intel has plans on when to issue “reactive” NDAs to customers several weeks before the “proactive” and “public” disclosures. [Editor’s emphasis] That begs the question of reacting to what? If it isn’t being exploited, there is nothing to react to before it is disclosed, right?
Back to the point, what is the issue? Again we won’t be specific until the fixes are out but on April 25, Intel released a firmware fix for this unnamed issue. It affects every Intel machine from Nehalem in 2008 to Kaby Lake in 2017. The vulnerability affects AMT, ISM, and SBT bearing machines. For those not up on Intel security acronyms, this is every Intel box shipped with an Intel chipset for the past decade or so.
Depending on whether you are a glass half empty or half full type, there is a bit of good news. This flaw is remotely exploitable only if you have AMT turned on, that is the ‘good’ news. The bad news is that if you don’t have it turned on or provisioned the vulnerability is still exploitable locally. If you aren’t the half full type, you might sum this up by saying there is no way to protect a manageable Intel based computer until this hole has been patched, it is that bad. Let me repeat, you can not protect a manageable PC or server with this flaw until there is a patch, period. This flaw is present in ME firmware from version 6.0-11.6, things before and after those numbers are not affected probably because they used the AMT engine with the non-ARC CPU cores in older iterations.
Luckily Intel has some mitigation options for the affected users, that is you, whether you know it or not. They have two fixes for provisioned AMT and non-provisioned boxes, both prevent the issue from happening until the firmware update has been distributed by OEMs. Unfortunately since this issue is not disclosed officially yet, they won’t tell you what it is. Due to the severity of the issue, we highly recommend you make these changes immediately, don’t wait for the official disclosure.
If you have provisioned AMT or ISM on your systems, you should disable it in the Intel MEBx. If you haven’t provisioned these, or have and want to mitigate the local vulnerability too, there are more steps to take. If you have a box with AMT, ISM, or SBT, you need to disable or uninstall Local Manageability Service (LMS) on your boxes. Intel helpfully points out that doing this will mean your box can’t be managed using those services when you disable them. If this makes you think about whether or not to disable those things, trust us, don’t think about it, disable them NOW.
This brings us to a very ugly point. Intel has put AMT and it’s variants into every device they make. Some you can’t see because it is fused off but off is a very strong term. There are several features that AMT provides that are present in consumer systems even though the ‘technology’ isn’t there. This is one of the arguments that SemiAccurate has had with Intel security personnel over the years, we have begged them to offer a SKU without the AMT hardware for just this very reason. Intel didn’t, the pressure to lock corporate customers in to their silicon was too high.
With this exploit, every Intel box for 9+ years is now vulnerable because you couldn’t buy a box without it even if you wanted to other than a few older 4S servers. If you deployed Intel’s management solutions like AMT or SBS, you know the ones we mocked, you now have to turn it off or face remote exploitation. If you are a large corporation with AMT deployed, and most companies have deployed it, turning it off is easy, just a console command or three and it is done. Turning it back on however means going to every desktop, laptop, and server in your organization manually patching the BIOS and ME firmware, then turning the ME features like AMT back on. Manually.
This all assumes that there is a patch for your machine. Intel has a slew of BIOS/ME firmware patches out and in the hands of OEMs now. From here it isn’t Intel’s problem, and we mean that without even a hint of sarcasm. Intel has done their part and delivered the updated firmware to OEMs, it is now up to them to do the right thing. Some will.
The problem from here is twofold starting with no-name PCs. If you have a white-box PC or one from a sketchy vendor, chances are they won’t bother with a firmware update. Security is a cost center and most OEMs run on margins too thin to bother with security patches even if they cared. Most simply don’t care.
On the other hand OEMs who do actually care, that would be most of the big ones like Dell, HP, Lenovo, and so on, will put out patches for their machines. The second problem is for how long? No not for how long will they keep patches up but how far back will they issue the patches for? Most OEMs don’t patch things out of warranty for good reason, this is a fair thing for them to do. Most PCs have a one or three year warranty with five being the rare exception for some boxes like servers. Most of the PCs in this category from tier 1 and 2 vendors should have patches issued in short order. Check for them daily and apply them immediately, really.
At best though this means there will be patches out for less than half of the affected machines. Do you or your organization have any machines in service but out of warranty? I’ll bet you do. What about embedded devices that are increasingly PC based? Digital signage perhaps? Industrial controls. HVAC. Security systems. Flight controls. Air traffic controls. Medical devices. I could go on but all of these are likely PC based and anything infrastructure related is likely networked, management engine enabled, and quite possibly in warranty from the service provider. But quite likely out of warranty from the board vendor who made the underlying PC the service it is based on. Do you know what is in your systems? I’ll bet you think you do.
So this Intel AMT/ISM/SBT vulnerability is the proverbial ‘big one’. It is remotely exploitable if you have Intel’s management solutions in use, locally exploitable if you have them provisioned in your machine. You have them on your machine. You really need to turn them off, uninstall all the pieces, and do it now, don’t wait for the official word on WW26. That is the end of June for non-Intelspeak people, they will officially issue this guidance then along with OEM disclosures.
Because SemiAccurate strongly suspects this vulnerability is being exploited in the wild as we speak, you should take the official mitigation steps as soon as possible. Then contact your OEMs and strongly suggest that firmware patches for every system, including-out-of warranty systems, would be appreciated by you. Then go over every embedded Intel board with a fine tooth comb. Remember it is every Intel system from Nehalem in 2008 to Kaby Lake in 2017, ME firmware version from 6.0-11.6. If you have or suspect you have these, act now. Really. This is the big one but you can take some corrective action before it is too late. Richard Stallman was right about firmware, and there are alternatives now too.
TLDR; Average computer user - If your system is 10 years old or newer it is likely exploitable, check for patches daily and install all patches immediately. If there is no patch, back up data and replace.
https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
Are consumer PCs safe from the Intel ME/AMT exploit?
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.
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?
https://semiaccurate.com/2017/05/03/consumer-pcs-safe-intel-meamt-exploit/