Every description I've heard of it has language like this:
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.
In absolute terms it's probably not as bad as a desktop operating system, which is laboring under sisyphean compatibility constraints on top of huge attention from researchers and a nearly totally intractable threat model. Relatively speaking, though, those same things must be taken into account - their attack surfaces are thousands of times bigger and they attract thousands of times more attention. Seeing about as many critical vulns in the AMT as in, say, the entire Linux kernel... yeah, I'd call that "awful code quality".
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.
>Seeing about as many critical vulns in the AMT as in, say, the entire Linux kernel... yeah, I'd call that "awful code quality".
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.
>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 !
Filter Linux's list to "scores > 8" to take the sampling bias into account - the only way to observe an AMT vulnerability in the first place is to gain remote super-root on a widely-deployed core system that may be a PITA to patch. That takes linux down to 27 for 2017. Of those, only about ten are for the kernel itself rather than for binary drivers for nvidia, broadcom, qualcomm, or htc hardware. About half of the total are marked "android"; given that my understanding is that the android kernel has significant changes I wouldn't be surprised if those are android-only exploits. The intersection leaves a grand total of 6 vulnerabilities that are in the actual linux kernel and comparable in severity to the two AMT compromises we've seen.
> 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.
Sure but as a user of Linux, I don't particularly care why the bugs are present in Linux. My view is if you ship it, you should own it. Assigning blame to Nvidia or whoever can go both ways. They might point the blame back at the interfaces inside Linux for being unclear or less than adequately documented, or whatever. Or they might blame some other aspect. Nobody knows unless you're the person who actually wrote the code or has intimate knowledge specific to the bug. In any case, my point wasn't to compare Linux vs AMT. I'm considering deploying ME/AMT to manage systems inside our office. After all this news having come out, I'm waiting till the dust settles. I have to unfortunately wade through a lot of hype to get to the meat of the issue. So far I haven't seen anything that would dissuade me from deploying ME internally.
The problem is the location of the vulnerablities: on the CPU itself.
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.
Sure, but I see no reason not to be able to just re-flash the ME firmware in that case. I guess as an embedded developer, maybe I'm just seeing things from a different POV than most people here.
Well, the easy way to flash the firmware goes through the ME, so that's about as good at removing infected ME firmware as Windows Update is at removing viruses. The other way... I mean, you could simultaneously bring down every computer your company and its employees own, airgap them all, open the cases, expose the SPI headers, flash the firmware, bring them all back online, and hope you don't have to do it again tomorrow because someone didn't get the memo and was working from home that day. And that nobody did anything Bad while they owned your entire corp net. You could do that. I wish you the best of luck.
I dont understand. Why is reinstalling an OS a solution to a rooted OS but re-flashing ME/AMT isn't? You patch the OS bug that lead to it being exploited, and you patch the ME bug that lead to it being expoloited. I'm assuming a scenario where Intel (and/or BIOS/UEFI/MB vendors) behaves like a sane OS vendor and releases regular updates/fixes. Anyway, we're really geting far off topic. I guess I'm replying too :)
Anyway, we're really geting far off topic. I guess I'm replying too :)
Heh, I'm here to have interesting conversation, not necessarily on-topic conversation. :P
Why is reinstalling an OS a solution to a rooted OS
but re-flashing ME/AMT isn't?
The issue is that it looks to me like there's no equivalent to "reinstalling the OS", since the non-SPI route for flashing the ME is an ME function. That's why I used windows update as an example - flashing new ME code is less "boot from install media and reinstall" and more "sudo dpkg -i new-kernel.deb" or "run windows update". And if the ME is compromised - dpkg/winup in this analogy - it could easily propagate itself to the new firmware. Since at least some of the vulnerabilities are in bootloader code that's stored in ROM, it may be flat-out impossible to prevent the ME from compromising the new image if it's running while you're flashing - IOW, time to crack the case and find the SPI headers.
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.
Yeah, this is the kind of info I'm trying to figure out. The ME update mechanism seems to not be so cut and dry. The three regions RGN/EXTR/UPD can be updated seperately. It seems like ME updates could be delievered either as a full OEM bios update, or a by an Intel supplied UPD-only update. Also, The update seems to be a simple direct flash via the SPI controller. Not sure if any running ME processes can interfere with that. Happy to go through any links you have..
Now that I think about it, I'm not sure that the exact route matters. The ME can read and write its own firmware storage; that's a necessary capability for writing new firmware with the MEI. So if a compromised ME gets a chance to execute code after new firmware has been flashed, it can read out that new firmware and reinfect it. 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? I can see setups where it's impossible to be able to get access to firmware storage with the ME offline. This is getting way into the details of how these motherboards are wired up.
> So if a compromised ME gets a chance to execute code after new firmware has been flashed, it can read out that new firmware and reinfect it.
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.
You can normalize against anything. Can we normalize Linux against the fact that millions of people potentially could have reviewed the source code, and prevented the bugs? You can bias things with proper justification any which way. At some point, we just have to accept an imperfect method :)
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.