3 ms·

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 h

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.

ksk 9y ago
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.
- saulrh 9y ago
  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.
  - ksk 9y ago
    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 :)
    - saulrh 9y ago
      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.
      - ksk 9y ago
        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://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf https://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...
        saulrh 9y ago
        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.

ksk 9y ago

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.

saulrh 9y ago
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.
- ksk 9y ago
  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 :)
  - saulrh 9y ago
    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.
    - ksk 9y ago
      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://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf https://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...
      - saulrh 9y ago
        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.