This is also what the management engine cleaner project is for: https://github.com/corna/me_cleaner
https://github.com/corna/me_cleaner/wiki/How-to-apply-me_cle... The procedure seems far from trivial and requires special hardware(?). Is there a guide or some resources I could follow as a person with no hardware/low-level technical knowledge?
There is no good solution for Intel chips.
You could sidestep the whole issue by buying a C201 chromebook (quad-core ARM) and putting Linux on it.
Great news that this finally came to light. After learning about remote management capabilities I've always suspected it had holes. Large attack surface, any exploit would have a high value, and closed source. Perhaps one day we'll be able to buy CPU's without this "feature". I'm betting AMD and ARM are in the same boat.
> After learning about remote management capabilities I've always suspected it had holes. Large attack surface, any exploit would have a high value, and closed source. Even after reading this, I'm still not convinced it does have holes. It's so high value (pervasive, incredibly powerful, and old) that if it were possible a bad actor would have used it . The spectrum of possibilities is small: 1. The hole does not exi…
My ignorance is showing, but what product lines are impacted? Obviously things like Xeons and Core iXs, but what about things like Atom processors in tablets?
Intel says Enterprise grade hardware is affected, not consumer grade.
It'll be interesting to see how Intel deals with it.
Looking at the recent Atom failures (with vendors told in no uncertain terms to present publicly as generic "timing component" failure), will they even admit it's an ME thing?
It might not be trivial, but you can do this w/o the ME. My understanding is that most ethernet cards support a "Wake-on-LAN" feature to turn off machines on, and from there you can trigger the machine to reboot and then netboot (by writing to its boot config to instruct whatever boots it that it should take that action). Even if you assert that the ME is absolutely necessary for such a use-case, I don't have that us…
Just get a computer that doesn't have vPro.
That disqualifies a lot of otherwise really good hardware. My current Thinkpad, for example, and all current MBPs, I believe. Some manufacturers also aren't very clear about the exact hardware in their machines, either. (For example, Apple doesn't list the exact CPU on their tech specs page, only the somewhat vague "2.4GHz dual-core Intel Core i7, Turbo Boost up to 3.4GHz, with 4MB shared L3 cache". That might be unambiguous enough to map back to an actual piece of hardware, but it's still a considerable amount of work to do so.)
The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware. We knew this would happen. We knew that the Management Engine was a backdoor, and we knew it was only a matter of time before someone would figure out how to exploit it. This is exactly the reason why Libreboot exists (…
If the verilog to the chip isn't open, you can't trust it. Stallman is dangerously wrong on this point.
Somewhere you have to externalize trust. What use is the open HDL code for a chip if you cannot be sure someone down in the manufacturing chain hasn't... modified it?
Certainly this kind of attack is not your average script kiddy but nation-level instead, but I wouldn't put it past the NSA to pull this off.
The article sort of reads like he has thought (not known) there was an issue for a long time. Then, he saw that Intel released a patch related to the management engine, and took that as confirmation? Maybe he has access to the release notes via a source at an OEM?
He got the affected version numbers exactly right, but according to Intel he got the affected hardware wrong (consumer hardware unaffected). That tells me he got the information from an unmentioned source. If he had the details himself he would be able to confirm what hardware it is present on by testing it. The explanation for that error code be that the source have been vague about it or not tested it on a lot of h…
Ah. To be fair, that intel.com link is confusing, because it sends you off to see if you have "Intel® vPro", which is certainly on consumer hardware, like various i5 and i7 systems. Which does not jive with the earlier line "This vulnerability does not exist on Intel-based consumer PCs". It sort of depends on your definition of consumer hardware.
Overall, though, it does seem to validate the sequence was something like "he had a suspicion" then "intel released an update".
> For obvious reasons we couldn’t publish what we found It's not obvious to me why anyone not under an NSL or NDA would sit on this vulnerability for 5 years and wait until it's actively being exploited in the wild before public disclosure. It's extremely negligent to global security for SemiAccurate to not immediately publicly disclose the vulnerability 5 years ago after Intel refused to fix it. Of course this is ig…
If the verilog to the chip isn't open, you can't trust it. Stallman is dangerously wrong on this point.
Somewhere you have to externalize trust. What use is the open HDL code for a chip if you cannot be sure someone down in the manufacturing chain hasn't... modified it? Certainly this kind of attack is not your average script kiddy but nation-level instead, but I wouldn't put it past the NSA to pull this off.
Correct, you do need to externalize trust somewhere, but the Richard Stallman level of "chips are ok but firmware is not" is not the correct place for it.