Question: does me_cleaner still work after the recent ME patch from Intel?

[ndorf]

As you probably know, Intel has recently admitted to some serious security vulnerabilities in the ME, and released a patch: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

The obvious question is whether or not this patch will prevent me_cleaner from working, whether intentionally or not.

I'm told (but have no way to confirm) that the patch is included in recent Windows 10 updates, so anyone using that OS will be hard-pressed to avoid it.

[matt123b]

It should work the same. Why not try it and find out?

[syboxez]

A somewhat related question. Is it possible to downgrade ME after updating? I ask since this exploit allows the use of unsigned code, which means we could possibly have a libre ME replacement.

[mooms06]

If you have an external flasher you can flash any version of the BIOS/ME, even if the mobo manufacturer blocks the downgrade.

[corna]

@ndorf It should work.

@syboxez AFAIK there isn't any built-in anti-downgrade protection in Intel ME, but software flashing tools may prevent you to rollback to a previous version. The BIOS might refuse to boot if it finds a vulnerable ME image.

I'm going to test me_cleaner on an updated ME image shortly, I'll let you know.

[skochinsky]

There is a downgrade protection in ME, but only when using online/local upgrades with fwupdl[64] (which relies on the ME itself and won't work with a cleaned firmware). Nothing prevents you from putting a lower version firmware directly onto the flash chip, as long as it's compatible with the underlying hardware.

[atlury]

There is now a physical attack anti rollback protection. @skochinsky and @corna

Even after this we will be able to downgrade??? Attached

[atlury]

Further

Starting ME12.x, when incrementing the SVN, the new SVN value will be saved permanently in Field Programmable Fuses (FPFs) as a means to mitigate physically downgrading Intel® ME FW to a lower SVN. The mitigation occurs in Intel® ME ROM which validates the FW contains a valid SVN on every boot. All of Intel® ME data protection keys are cryptographically bound to the security version number located within the FW (SVN). This prevents data, such as disk encryption keys, from being accessed by the attacker following a downgrade.

Intel® ME will only allow systems to boot where Intel® ME FW SVN ≥ SVN FPF HW value. In case where FPF HW SVN > Intel® ME FW SVN, the platform will not boot. Recovering such downgraded systems will required physical flashing to Intel® ME FW SVN ≥ SVN FPF HW value.

[skochinsky]

Thanks for the update @atlury

[probonopd]

In the linked Intel document it says

OEMs may provide any concerns to Their Intel ® Representative

OEMs: Tell Intel that you are concerned that your customers don't want to buy NSA backdoors, and you want these removed from the Intel systems in order not to lose your customers.

[ndorf]

OEMs: Tell Intel that you are concerned that your customers don't want to buy NSA backdoors, and you want these removed from the Intel systems in order not to lose your customers.

The Libreboot FAQ states:

Even Google, which sells millions of chromebooks (coreboot preinstalled) have been unable to persuade them.

[halmartin]

@atlury AFIAK the ME has included a security version number (SVN) in the header for several generations:

The firmware security version number in the manifest header is an important field for managing firmware update or downgrade for cases where vulnerability is found and patched.

X. Ruan. (2014). Platform Embedded Security Technology Revealed [Online]. pp. 98. Available: https://link.springer.com/book/10.1007%2F978-1-4302-6572-6

There is more discussion about downgrade protection on page 114.

The author doesn't mention which ME version they are discussing, but the publishing date would imply the SVN has existed since before ME 11.

You mentioned:

Starting ME12.x, when incrementing the SVN, the new SVN value will be saved permanently in Field Programmable Fuses (FPFs) as a means to mitigate physically downgrading Intel® ME FW to a lower SVN.

This sounds like Intel is choosing to implement this policy on ME12, although in theory they could also start enforcing this policy on lower ME versions as the SVN and FPFs are present.

[skochinsky]

in theory they could also start enforcing this policy on lower ME versions as the SVN and FPFs are present.

That's going to be a little difficult since it has to be implemented in the ME ROM which is presumably not upgradable. If you implement it in the fw modules, the attacker can just reflash the old one without the check, and the ROM will run it since it has a valid signature.

[halmartin]

@skochinsky Good point, I didn't consider that it would have to be implemented in ROM.

I guess until now Intel only considered using SVN to prevent downgrades on a software level. With ME12, they'll enforce it in ROM, preventing downgrades through hardware flashing as you noted.

[atlury]

@halmartin Yes Indeed they may enforce it in ROM. I wish they had just gone the u-boot route like ARM. Could have made so much sense.

[skochinsky]

Yep, as stated in the book:

The ROM is the root of trust of the embedded engine. Note that physical tampering and fault injection attacks are out of scope.

[rminnich]

The libreboot faq is not quite right. Yes, you can not remove the ME completely. But chromebooks run a "downgraded ME" image which is only 1.5M, and as you might guess, that is not a feature-complete ME image.

[matt123b]

I opened an issue on this about my X230. The process works exactly the same when flashing externally. I'm not sure about internal flashing, since I never do that (due to painful past experiences with it).

https://github.com/corna/me_cleaner/issues/134

[ndorf]

The libreboot faq is not quite right. Yes, you can not remove the ME completely. But chromebooks run a "downgraded ME" image which is only 1.5M, and as you might guess, that is not a feature-complete ME image.

Not feature-complete, but probably still bug-complete: https://mobile.twitter.com/rootkovska/status/938458875522666497?p=p

[ghost]

@ndorf, Thanks for that tweet, do you know what she means (in that tweet) by "so ME "disabling" by HAP is not a cure"?

Do you think we should revert back to using the original removal method? There's no mention of AltMeDisable though, not sure if the same concept applies.

[ndorf]

@mastad0n I am about as far from an expert as you can get. My interpretation, though, is that the vulnerability is in the very core (kernel?) of the ME firmware, which apparently still runs even if the HAP bit is set. That would seem to imply that the original removal method would still leave one vulnerable, as it also disables whatever "non-essential" ME features it can, but leaves the core alone. Hopefully, someone more knowledgeable can elaborate and correct me where I'm wrong.

[corna]

@mastad0n the vulnerability exploits a buffer overflow on a file located in the MFS (the SPI ME file system) loaded by the BUP module, which must be kept to correctly boot the PC. The only fix is an updated ME image, neither the code removal nor the HAP bit can fix this vulnerability.

[ghost]

@ndorf @corna Thank you both for explaining what I didn't understand. It makes sense now.

[hyperfekt]

Thank you @corna! Consider putting this info on the wiki since I've read from many people that they wanted to use me_cleaner instead of upgrading their ME image, especially because it was unclear if the updated image could still be 'cleaned'.

[corna]

Also consider that the patch from Intel doesn't completely solve the bug: an attacked needs write access to the ME region on the flash to exploit the vulnerability, but in that case he can also rollback the updated ME firmware to a vulnerable version and then exploit it, as there isn't an hardware rollback prevention mechanism.

TL;DR keep your PC in a safe place and restrict the write access to the ME region.