At my work we use AMT for legitimate purposes: remote administration and support (we have offices in different cities). A big problem for us is that the AMT crashes by itself and the computer needs to be power-cycled for the AMT to work again. Sometimes the web-interface don't answer, sometimes the passwords doesn't match anymore. I think there is a process that is writing where it shouldn't, because it works again after the computer is power-cycled by removing the power-cord.
I now have a script that checks every registered computer twice a day , to see if it is still possible to login to the AMT, and if not, it sends an email to a person at the local office requesting them to restart the computers that fails.
When it works it is a great tool, allowing us to fix computers and give support without the need to travel to each city.
IBM, Dell, HP, etc. all had problems like you described where the management processor would hang after receiving unexpected traffic (e.g. nmap scans), too many simultaneous logins, etc. and, naturally, nobody had thought to implement a watchdog timer to reboot if it became unresponsive even if they had the same functionality available for the actual server.
Or this was a deliberately inserted but deniable backdoor.
AMT is a large module with a huge number of
different network protocols of various levels
integrated into it. This module contains a great
deal of legacy code but can only be found in
business systems.
Plus there's the fact that the original vulnerability was literally "you can get in by sending an empty password". A culture that lets a bug like that through cannot be conducive to good code.
But that is not the case. Linux has had 400+ security bugs this year (as you point out, in part due to its greater attack surface) versus the 2 from AMT. I'm trying to reconcile this idea that "ME = BAD" in a practical way by comparing it to software that's in mass use and already being exploited. The tech press over time has needlessly over-hyped such security issues making it harder to put things in perspective. So far, I'm not seeing anything special about ME that would also not apply to many many other products.
https://www.cvedetails.com/vulnerability-list/vendor_id-238/...
https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
>Plus there's the fact that the original vulnerability was literally "you can get in by sending an empty password". A culture that lets a bug like that through cannot be conducive to good code.
I don't see the tech press not recommended OSX anymore !
https://www.theregister.co.uk/2017/11/28/root_access_bypass_...
> I don't see the tech press not recommended OSX anymore !
I certainly don't rec apple. Never have, though previously for non-security reasons, and unless they do a lot of changing, never will.
Get pwned in linux? Nuke and pave can usually solve it. The exceptions being BIOSes and hdds/usbs with vulnerable firmwares which can be exploited to restore the malware. However in that case an actor has to target your hardware combination specifically, and there are a plethora of different hdd/usb manufacturers.
Get pwned in ME? No longer your hardware. On top of that it applies to all Intel CPUs, and potentially remotely to Intel AMT CPUs.
Anyway, we're really geting far off topic. I guess I'm replying too :)
Why is reinstalling an OS a solution to a rooted OS
but re-flashing ME/AMT isn't?
Also, really, reinstalling the OS is a solution to a rooted OS only almost all of the time - a truly determined infection can lodge endospores in places like GPUs and hard drive controllers. They just don't do that kind of thing because the spectacular range of PC hardware makes that capability cost-ineffective. If they can find something like that for the ME, or if they don't even have to because they control the only way to update firmware and it's the same on every intel system, that's a much higher-value target.
https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf
https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...
Yeah, or it could just fake the flash operation. Much easier than re-infecting a potentially unknown firmware. Lots of oppurtinities here.
>And that means that even direct flash via SPI won't work unless you can take the ME offline, flash the firmware, and then restart the motherboard without ever giving the compromised firmware a chance to do anything. Which I'm not sure is... entirely possible
It looks like the ME processor can execute instructions from the firmware/spi region, its own memory, or from a reserved region in RAM. During the SPI flash, if the ME CPU is not offline, then it has the potential to accidentaly execute instructions out of the firmware region being flashed to and cause havoc. This may necessiciate that the ME MCU enter some kind of idle state during flashing, and then be rebooted. Although, as an aside, maybe the flashing works by copying to an unused region and then fliping a 'new firmware at location X' bit and rebooting the ME CPU which will then do the actual flashing. I haven't found any details yet, but I haven't looked that hard either.
Until very recently, independent researchers had no access at all to the instructions that the ME processor runs; maybe normalise against that? http://blog.ptsecurity.com/2017/12/huffman-tables-intel-me.h...
This is not the correct comparison. AMT has terrible code quality compared to the gateware/microcode of your average x86_64 CPU.
That ME/AMT is as insecure as some consumer OSes is no excuse, especially given it's certainly quite possible to install an OS on your x86 machine that is far more secure than your average consumer OS (or than the code AMT runs, which apparently falls to 1990s-vintage buffer overflows).
I think comparing the code quality of the AMT to that of another OS is a fair comparison, given that the current-gen AMT is running a modified version of MINIX[1].
[1] https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...