Here's hoping. Intel did a great job hiding the thing and making it all but impossible to remove (at present if you nuke the firmware, the CPU will totally fail to initialise. Thanks Intel!). That said, we're talking about an embedded device with very low-level code, and any 'disabling' code is probably going to be distributed in binary form. Stands to reason somewhere along the lines, someone is going to turn that around for their own benefit.

In tin-foil hats, we trust, more like!

I just get tired of being ridiculed and then 10 years later vindicated.

In Faraday cages we trust.

2013 was the greatest 'WE TOLD YOU SO' in history for the tin-foil-hat brigade...

Why 2013 specifically?

Presumably because of https://en.wikipedia.org/wiki/Edward_Snowden#Publication

Yep, this exactly.

Imagine how Stallman feels.

There's a whole subreddit dedicated to this https://www.reddit.com/r/StallmanWasRight/

You'd think after being right again and again people would start to trust you. Or at least distrust entity that have a track record of behaving badly.

And yet...

me_cleaner already exists[1], and it takes advantage of several flaws in Intel ME's signing to remove large sections of the code thus neutering it. Some code still exists, but Intel ME cannot actually fully initialise on "cleaned" systems. Older machines used to have a bug where if you filled the first half of the Intel ME firmware with zeros the machine would boot but ME wouldn't start at all.

But yes, I hope that with this it'll be possible to completely remove the remaining few hundred kB of Intel ME code remaining.

[1]: https://github.com/corna/me_cleaner

Is this enough to block this attack? That is, is a "cleaned" system vulnerable to a USB device?

> That is, is a "cleaned" system vulnerable to a USB device?

of course it is, because the USB DCI attack is one level below the Intel ME. Even if it is deactivated via HAP, which basically simply puts the ME code into an infinite loop or a CPU halt state - both can be reversed by JTAG.

I don't know, because there is very little detail about what this attack is and how it works. It looks like they managed to thwart whatever protections exist in the USB DCI (Direct Connect Interface)[1] which is a debugging system for Intel chips.

If they have full debugger access to what's running in Intel ME then removing the code from the firmware probably doesn't make a difference (assuming they can run un-trusted code in that context). If they cannot write their own code and so an attack requires ROP gadgets then removing the code might make it harder (or impossible) to do, but I doubt it.

[1]: http://www2.lauterbach.com/pdf/directory.pdf#M8.newlink.DIR6...

DMA/Firewire over USB makes pretty much every systen vulnerable to USB attacks (ME aside.)

DMA-based attacks are blocked by the IOMMU, which is present in all modern machines (and has been for a few years). Linux has preferential enablement of DMA such that the IOMMU is initialised first, so even plugging in a device in early boot will not be able to exploit DMA.

Does it? To use the IOMMU for VFIO, I had to explicitly enable it via a kernel parameter.

Until they fix it. Or use something else.

Huge corporations backed up by gov agencies with a lot of time, money and skilled people VS a few people working for free because they believe they should. Not a fair fight.