That's a lot of computers worldwide.
Remote access to DMA capability is just batshit insanity.
It's still an OS, it's just not on the hard drive.
The real issue is that we don't have the source code for it and only the OEM can patch security vulnerabilities -- or not.
The AMT can't be completely disabled, so people might not have to explicitly enable it to be vulnerable to AMT exploits.
> It's not like every Intel system is silently waiting for an exploit payload.
It's not like it's Intel makes it easy to navigate their CPU and motherboards feature set. Manufacturers are also known to do a bad job on their BIOS/EFI. And given that the computers most likely to be vulnerable are those most likely to be used by businesses and professionals, the damage potential is pretty staggering. But yeah, netbooks are probably safe.
There's a reason you want to keep the amount of softwares installed on a critical system, other than performance.
These AMTs/MEs/whatever they call them are full-blown computers with non-trivial firmware/software. The question is: do Intel and AMD put all that much effort into making that secure? (That's quite aside from the possibility of intentional backdoors, which one would think would be reasonably secure so that only NSA and friends could use them.) The answer is "almost certainly not enough effort". This sort of device calls for using Coq or similar provably correct software construction -- it is much too critical to do otherwise if you're going to make it impossible to disable these things.
I guess we just have to filter these ports for a while now -- a big hammer for a big problem.
It's also time for customers to insist on these things being off by default.
The intel remote control firmware is a rootkit that lives on many many systems for which the full features and capabilities of, along with all vulnerabilities, are kept as trade secrets.
"Traditionally", Ring -1 is the Hypervisor your kernel is running in, -2 is code running in SMM (e.g. BIOS USB legacy support code), and -3 is the firmware on your physical system (chipsets, hard drive firmware, etc).
It's worth noting that the reference to "system privileges" being attained likely refers to something much more privileged than we would normally ascribe to "system privileges". Normally, "system privileges" would mean something SYSTEM on Windows or root on Linux. In the event of "system privileges" in the management component, remember that the main CPU is a slave to this thing.