Hacker News new | past | comments | ask | show | jobs | submit login

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

https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf

https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: