I'd be surprised if this actually disables all aspects of ME and AMT. Those things listen when the computer is off, and cause a CPU shutdown when deactivated unless you are work hard to subdue them (recent CCC had a presentation on what's needed).
You can run netstat and see it is no longer listening. Now, how you would verify this when the computer is off is beyond me (assuming it is the case - I have not yet been able to go thru the PDF below)
The thing that was listening is just AMT. The ME consists of a much wider suite of behaviors.
For example: there's an embedded-profile JVM for running Java Card smart-card software, allowing enterprises to deploy crypto auth firmware written for smart-cards directly to the device. This avoids the need to flash, deploy, and manage hardware smart cards, while also preventing the OS from being able to introspect said software's operation. (This particular feature almost sounds like a good thing, doesn't it? It's a programmable TPM!)
Hmm, a programmable TPM / secure element running as a program on an undocumented OS that also runs a web server and is probably not hardened (and might not even have privilege separation or even an MMU for all I know) but nonetheless has superpowers over the main CPU. I'll stick with a hardware TPM, thank you very much.
(Qualcomm's TrustZone kernel runs on a similarly limited but much better documented platform, does not run a web server, and has had a good share of vulnerabilities over the years. I see no reason to expect Intel's ME software stack to be any better.)
You misunderstood what ME is - it's not only a piece of software running in your operating system, but also an entirely separate processor that runs its own firmware.
It has its own network stack and entirely bypasses the operating system - you cannot see it listening using netstat, you wouldn't even see the actual communication using Wireshark. It works even when the computer is off (which makes sense for an out-of-band management solution).
I don't know; presumably organizations like the US military need some way of "hardening" Intel's chips after they receive them. This SCS tool could be how such organizations accomplish that.
Seeing as we know Amazon can get Intel to make custom Xeon chips specifically adapted for EC2 usage, I'm 100% certain Intel also makes custom chips for military/etc applications that have whatever functionality the customer does (doesn't) want enabled (disabled).
So that means it's still exploitable over the network? (I thought it would cut it down to local-only). Lenovo is lying to me when it says "disable AMT"?
Then again, maybe it's not actually enabled, since I didn't use the software to do so.
That is a good question. Lenovo's advisory (https://pcsupport.lenovo.com/us/en/product_security/ps500104) does not explicitly states which AMT status make it vulnerable, but given that Intel ME runs no matter what, I'd go for the disable guide.
Unless you modified your BIOS with a SPI flasher after disassembling your device, you know it's still running :-)
It would disappear from the PCI bus.
Your commands un-provision AMT (Active Management Technology), the ME feature that apparently has a security issue. Unless you've explicitly enabled AMT, it's not provisioned anyway so this doesn't do anything.
May be worth reading the coreboot wiki, I remember reading about the different subsystems of AMT, and it seems plausible that you can set it into a state where control functions are disabled. But my memories are very blurry.
Still coreboot guys are quite experts on the matter.
I thought so too at first but I guess whereas the title now says "Completely Disable Intel AMT on Windows", it probably used to say something along the lines of "Completely Disable Intel ME on Windows".
Edit: The title has been changed again and now reads "Disabling Intel AMT on Windows". That's better and less confusing.
It's worth mentioning that on some systems it's possible to permanently disable the management engine and the MEBx extension BIOS by selecting the "Permanently Disable" option from BIOS.
There's a good chance it is since they worked with the group trying to DRM everything. The NSA was also in that group likely trying to simultaneously secure and backdoor everything. A built-in backdoor sold as a business benefit that you can't turn off at all from a defense contractor in a police state is already 90% to being malicious just by nature of the situation. So, assume it is at least for the local police state and their partners.
Now, if that's not in your threat model, then you'll probably be fine using it unless foreign adversaries are in your threat model. And the rabbit hole of how threatening are live backdoors on your network just goes on from there.
There's at least calls to remove SIGINT agency from TCG:
These step by step instructions were built based on the mitigation guide, which is linked in the advisory. I've updated the HN link title and post's title (see https://news.ycombinator.com/item?id=14253732)
Ah, I understand. The Mitigation guide says: "Intel highly recommends that the first in all mitigation paths is to unprovision the Intel manageability SKU to address the network privilege escalation vulnerability".
Unprovisioning AMT seems to be the essential part and I am curious if the other steps serve any real purpose.
The Mitigation Guide goes on to say: "Systems that are vulnerable [...] should be unprovisioned using the tools used to initially configure them [...] As an example, the Intel AMT Configuration Utility [...]"
So ACUConfig is just an example and specifically not the Intel recommended way. OP doesn't say that.
Assume it's relative, until you can proof your BIOS is unable to communicate with the Wi-Fi adapter. If you are thinking "but it can't connect to a network", your OS will do that for you, at which time it can start communicating.
Isn't the entire point of AMT to allow out-of-band system management? If it relies on the OS to connect to Wi-Fi that would seem to kind of defeat the purpose. Is there any evidence AMT works on Wi-Fi for anybody? I tried pinging my laptop from another machine on the ports listed here and I didn't get any response over Wi-Fi, so I'm not sure how to interpret that.
Generally these things don't work over WiFi because the special back-channel between the NIC and the management CPU isn't there for WiFi NICs. But as others have said, it is in theory possible if someone were to build the required communication path into their NICs.
All AMD CPUs after FX have PSP which is efficiently the same thing as Intel ME and it's also can't be removed / disabled at all since it's participate in CPU boot sequence.
Oh great. Do we have any viable choice left in avoiding these 'helpful' blackbox modules? Viable meaning something that could run a medium-load server?
There is chance that POWER8 and future POWER9 based hardware might work, but it's very expensive. There was already an attempt to create backdoor-free hardware, but for now it's failed:
Dark times when even good old AMD is doing anti-consumer crap. I don't even get how this is helping their cause against Intel. They could have simply not done the stupid things Intel is doing and carved a niche. But this is just showing they want to be another Intel, not a better Intel.
Post-Snowden, I think you will find there are more who care about this than there were in the past. The only reason any of us take this seriously is because of what we factually know about government agencies snooping on us.
Problem is that bunch of nerds (myself included) is not viable market. PSP / ME it's just one of problems on hardware layer: almost every single device have closed source firmware or microcode inside drivers and there no device on motherboard that have DMA and can be trusted. Hardware manufacturing is hard and even if some company would be able to produce viable hardware there just not enough customers who going to pay 10-20 times of price premium just for security.
And even if you can mitigate hardware issues your "secure" system will be practically useless because on software layer best you can get it's PoC like CubesOS since desktop Linux is just damn insecure.
So if you want solution that actually let you have work done then you have to sacrifice something: keep important data on isolated always offline PC, get older hardware without PSP / ME (or deactivated one) for online and pray. Then always put newer untrusted hardware behind hardware firewall / VPN / etc.
In the end several completely isolated devices for different use cases give you much better practical security than one backdoor-free PC / server.
Fact that anyone official commented on matter is big deal, but it's still worth nothing and change nothing. AMD for instance has proprietary firmware on GPU too and their highly technical Linux staff (John Bridgman and others) confirmed many times they simply can't open it even if they wanted to due to all DRM-related certification, agreements with IP partners, etc.
And it's much worse in case of PSP because first of all it's ARM IP and they wouldn't be able to change anything without agreement with them. Also after a little of Google-fu I find interesting document:
That's mirror, but you can easily find source. So AMD actually pitch it not just to governments, but also defence institutions and this is just much much worse than story with DRM.
Also, I keep suggesting appealing to Intel or AMD's "Semi-Custom" business that modifies their processors or I.P. in customized ways. This undoubtedly cost millions of dollars. However, just taking out the ME or other bloat with only custom work being re-integrating proven components should be an easy job for their engineers. It's also way, way cheaper than designing an Intel- or AMD-class, x86 CPU. Maybe no patent suits either.
A company like Amazon or Google could easily pay for this to be done with their servers using enough CPU's to create the necessary volume to bootstrap sales of it. If it gets popular, Intel and AMD will likely release it as a product themselves.
This is the kind of brazen backdoor which makes all other security moot. How can anyone depend on security if the cpu is backdoored and anyone can remote your machine irrespective of OS and even whether it is running?
Given the sheer brazenness and scope I wonder why the security folks have been so muted, what can be more important this this?
What ever the benefits of this backdoor for enterprises or any single group imposing it on all users makes it look like a fig leaf. The fact that it is done in consort with AMD and ARM can only lead to the conclusion it is some kind of a mandated NSA backdoor.
There is a huge unresolved dichotomy now of 'democracies' with governments completely and singularly obsessed with their citizens' speech. Having hundreds of thousands of government employees working on monitoring citizens and doing things like backdooring CPUs is the furthest you can get from free societies. Infact it's the opposite.
It'd be nice to have something that actually disables these additional Intel "management" chipsets, across all platforms.
reply