Disabling Intel AMT on Windows | Hacker News Reader

Disabling Intel AMT on Windows

mattermedia.com

117 pointsgaia70 comments

This is taken verbatim from Intel's "SA-00075 Mitigation Guide" [1]

As others have said, it doesn't disable the ME. It merely removes OS-side support for it and resets configuration to non-exploitable state.

The ME itself remains up and running.

[1] https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20...

* To clarify - the original title of this post was something like "Completely Disable Intel Management Engine (finally!)".

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)

> It merely removes OS-side support for it and resets configuration to non-exploitable state.

How do we know that the vulnerability is in the OS-side? Has this been established yet?

It also un-provisions AMT, which supposedly prevent remote exploitation.

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.

ACUConfig is the Intel recommended way, per the mitigation guide (at least for now, until a patch is released).

Quote from the Mitigation Guide:

"Systems that are vulnerable [...] should be unprovisioned using the tools used to initially configure them [...]"

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.

This only disables the Windows driver.

The actual ME co-processor is still running.

And how would you test for that?

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.

> Your commands un-provision AMT (Active Management Technology), the ME feature that apparently has a security issue.

It disables the optional OS-side of AMT. How do we know that the vulnerability is in the OS-side? Has this been established yet?

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.

Unprovisioning disables both the OS side and the hardware AMT. It doesn't change anything if you never enabled AMT.

You are correct, I've updated the HN link title and post's title.

It's still rather misleading, "Completely Disable..."

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.

Why do you think Intel doesn't let users turn it off?

Because it's a hardware backdoor in the CPU?

That's probably not the reason. At least not in the malicious sense.

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:

https://www.securitycurrent.com/en/writers/richard-stiennon/...

It's not relevant to your threat model until it leaks...

Haha. Exactly. This should be a bigger concern recently since that's what keeps happening to good, attack tools.

So I'll repeat your question:

Why do you think Intel doesn't let users turn it off?

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).

Please add some substance to your post. Thank you!

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

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)

You can use something like nmap to scan open ports from another machine. Nmap can both do host discovery (find IP addresses) as well as port scans.

https://nmap.org

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!)

In fact, AMT isn't listening in the operating system either but directly on the ME.

What OP removed is probably some sort of OS-level agent that collects information about the system (installed software, patches, ...).

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.

Yea they say cut the AMT fuse.

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).

The closest thing I found that could work for Linux is flashing the BIOS manually: https://hackaday.com/2016/11/28/neutralizing-intels-manageme...

In the case of my Thinkpad, I had to open it up and flash the chip using the Raspberry Pi hardware over SPI bus.

Then I found out that removing the Intel Management Engine breaks Hackintosh so I ended up having to put it back.

Another alternative is flashing Coreboot/Libreboot, but this also breaks Hackintosh.

You'll be happy to hear that this no longer works with newer devices thanks to Intel Boot Guard, which prevents firmware modifications altogether.

I have a Lenovo T440s. My BIOS has an "activate/deactivate/permanently deactivate" setting for AMT. I set it to "deactivate" for now.

Any idea what this buys me?

Their last BIOS update was March 14. I'm hoping their next one has the new firmware.

Deactivation merely resets the AMT settings. You can only turn it off by following these instructions.

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.

I did not know about the advisory. Thank you!

This is copied from the Windows-only SA00075 Mitigation Guide from Intel.

Intel advised me that a Linux version of the Mitigation Guide is coming - https://twitter.com/IntelSupport/status/859437569368567811

Some riskier but possibly more effective solutions for disabling or at least limiting ME (AMT is one application that runs on ME):

https://github.com/corna/me_cleaner

https://hardenedlinux.github.io/firmware/2016/11/17/neutrali...

To be 100% clear, I haven't tried either.

See https://news.ycombinator.com/item?id=14253704

Has AMD done anything similar to this? I'm thinking of what hardware to buy in future, probably going to skip Intel-based going forwards.

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:

https://www.raptorengineering.com/TALOS/

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.

Sadly I don't think there is any market for secure hardware.

Simply no one care; not even enterprises and governments.

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.

AMD has recently stated they'd like to do something about this during an AMA on reddit: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...

This probably won't happen for a while, though...

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:

http://fileshare.arseniyshestakov.com/mirror/AMD_PSP_Briefin...

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.

That depends on how you define "viable". There are a couple of open platforms: https://en.wikipedia.org/wiki/Open-source_computing_hardware

OpenSPARC with something like Piton:

http://www.pcworld.com/article/3111693/hardware/open-source-...

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.

Dumb question: is any of this relevant for someone who only uses Wi-Fi and not ethernet?

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.

Seems Windows specific?

It'd be nice to have something that actually disables these additional Intel "management" chipsets, across all platforms.

Yes, windows only for now. The Linux guide is upcoming: https://twitter.com/IntelSupport/status/859437569368567811

Is that because the exploit only affects Windows? I somehow doubt that but just wanted to be sure.

Yes, the exploit is only for Intel ME on Windows, AFAIK.

This is not accurate

Out of the loop: Why would someone want to disable Intel AMT? I gather that there was an exploit?

start here http://www.fsf.org/blogs/licensing/intel-me-and-why-we-shoul...

Reply on news.ycombinator.com