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).
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).
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 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).
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.)
Comments
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).
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).
Yea they say cut the AMT fuse.
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 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).
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 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