Remote security exploit in all 2008+ Intel platforms

Updated 2x: Nehalem through Kaby all remotely and locally hackable

Intel - logoEvery 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.S|A

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.

The following two tabs change content below.

Charlie Demerjian

Roving engine of chaos and snide remarks at SemiAccurate
Charlie Demerjian is the founder of Stone Arch Networking Services and is a technology news site; addressing hardware design, software selection, customization, securing and maintenance, with over one million views per month. He is a technologist and analyst specializing in semiconductors, system and network architecture. As head writer of, he regularly advises writers, analysts, and industry executives on technical matters and long lead industry trends. Charlie is also a council member with Gerson Lehman Group. FullyAccurate