Which of the IntelME mitigation methods is most open and effective?
IntelME neuter (me_cleaner)
HAP AltMEDisable Bit Switch (BIOS/UEFI)
RISC-V
ARM (Rockchip)
Intel machine SPI chips can be flashed with Coreboot/Libreboot
It doesn’t look like RISC-V, or ARM has Coreboot/Libreboot support
There is still the issue of CPU microcode, part of which can be
lifted from the UEFI/BIOS firmware (/lib/firmware/intel_ucode/)
If you still want to use Qubes OS, the HAP disabling method is the most effective, followed by the HECI soft-disable method:
Have not heard of HECI IntelME disable method, can you describe this
method.
The HECI (Host Embedded Controller Interface) method is a way to soft-disable the Intel Management Engine (ME) by sending a command that puts it into a disabled state, but it does not completely turn off all ME functionalities. This method is commonly used by manufacturers and is not fully trusted by the community as it leaves some features operational.
I looked forward to RISC-V until I realized this world is too evil to allow backdoor-free CPUs to reach consumers.
@Quben Are you aware of any common desktop/laptop CPUs that have backdoors? Adding backdoors at hardware level is a very inconvenient place to put it. Backdoors are usually put at operating system level or app level, where is can be easily updated, and isn’t being questioned if discovered.
With that said, Intel ME is a total security disaster and should be HAP-disabled by anyone that cares about security. And UEFI firmware and CPU microcode kept up-to-date at all times, as security vulnerabilities at that level as dangerous as backdoors or worse gets discovered all the time.
Apple CPUs had an undocumented “feature” that could bypass memory protection.
It was used in the Triangulation malware by someone who not only knew it existed, but also knew exactly how to use it.
If we try to describe this feature and how the attackers took advantage of it, it all comes down to this: they are able to write data to a certain physical address while bypassing the hardware-based memory protection by writing the data, destination address, and data hash to unknown hardware registers of the chip unused by the firmware.
Update 2024-01-09
Famous hardware hacker Hector Martin (marcan) was able to figure out that what we thought was a custom hash was actually something a little different. It is an error correction code (ECC), or more precisely, a Hamming code with a custom lookup table (what we call “sbox table” in the text above).This discovery helps us understand the original purpose of this unknown hardware feature. We originally thought it was a debugging feature that provided direct memory access to the memory and was protected with a “dummy” hash for extra security. But the fact that it involves an ECC, coupled with the unstable behavior observed when trying to use it to patch the kernel code, leads to the conclusion that this hardware feature provides direct memory access to the cache.
This discovery also raises the possibility that this unused hardware feature could have been found through experimentation, but to do so would require attackers to solve a large number of unknown variables. Attackers could find values in a custom lookup table using brute force, but they would also need to know that such a powerful cache debugging feature exists, that it involves Hamming code and, most importantly, they would need to know the location and purpose of all the MMIO registers involved, and how and in what order to interact with them. Were the attackers able to resolve all these unknown variables by themselves or was this information revealed somewhere by mistake? It still remains a mystery.
HAP is purely cosmetic on some of the builds of Intel ME released after HAP was publicly disclosed.
The adversary puts new “mistakes”, new vulnerabilities, into newer UEFI or CPU microcode.
And you are claiming that the adversary here is Intel? AMD? This is a very serious claim. Please provide proof that Intel or AMD has intentionally introduced new vulnerabilities in a CPU microcode update, or for that sake intentionally introduced vulnerabilities in CPU microcode at all.
Also, it is very alarming that mentalities like this, that essentially suggest one should avoid updating UEFI and CPU microcode and keep running systems with known critical vulnerabilities is being expressed on this forum. CPU microcode vulnerabilities not too seldom enables an attacker who runs JavaScript in your web browser to compromise your whole system at kernel and hypervisor level, not to mention it is pointless to run QubesOS without up-to-date CPU microcode.
No one made that suggestion.
In that case I fail to understand why you objected to my suggestion to keep UEFI firmware and CPU microcode up-to-date.
What objection? What are you talking about? Is there some specific text you can cite?
I don’t know how else I should read your remark that the “adversary” (apparently you refer to the CPU manufacturer) will just put new “mistakes” (your quotes, so apparently you mean intentional vulnerabilities) into CPU microcode updates.
Given your avoidance to respond to me challenging your claims, I now believe your original claim was in bad faith rather than ignorance.
So, I will make a strong counter claim: Intel and AMD have never implemented any backdoor into any hardware or firmware, as evident by the lack of any reports of such backdoors despite much security analysis, and both vendors take security very seriously, as evident by them quickly fixing security vulnerabilities discovered and providing long security support.
Intel ME and AMD PSP are backdoors.
Why do you believe that? You are making very serious allegations with very farfetching consequences to security and privacy, all while providing no proof.
Do you have proofs? If not, stop spreading FUD so we can focus on actual security and privacy issues, not imagined ones.
Intel ME and AMD PSP are security and privacy issues. This is obvious to anyone who knows some basics on how computers work.
If Intel and AMD had already released the source code and adequate documentation for these spy chips and spy OS, then the story would be different.
True. Because they have full access to all RAM memory and all devices, bypassing CPU, so if an attacker is able to hack or compromise Intel ME or AMD PSP, they gain persistence at the highest level where the CPU cannot even detect it, and you have no ability to recover from the compromise. Which is why we HAP-disable Intel ME, so it cannot get compromised.
We can always hope. But binary blobs are not impossible to analyze. In fact, a lot of security researchers are analysing Intel ME and AMD PSP firmware all the time, and finding regular security vulnerabilities, which gets reported and fixed. No signs of any backdoor yet.
You admitted here you have no proof, and are spreading FUD, and acting in bad faith.
This eventually stopped working on releases of Intel ME some releases after the public disclosure of the HAP bit.
More “mistakes”. Totally organic and not intentional at all.
There is no body of source code that can compile software that can run as Intel ME or AMD PSP.
Anything actually useful as a result of analysis comes after a full decade later, or even later, long after users have moved on to other machines and hackers had all that time left without viable options.
Intel and AMD spread FUD in the form of software for which there is no source code.
HAP disabling works on my laptop with 12-generation Intel CPU (released 2021-2023 sometime). Allegedly it works fine on newer CPUs too, according to NovaCustom and Dasharo. So this statement from you is just a lie too.
Please take a look at Intel’s security bulletins for Intel ME. Security researchers are finding security vulnerabilities in the Intel ME firmware all the time. And surprise surprise, security researchers are used to analysing binary blobs, and don’t need source code. There is nothing here that is “a decade later”. So this too is a lie from you.
He doesn’t mean the CPU manufacturer. The adversary is the gxvernment that forces Intel and AMD to do this anti-consumer shit to further their plans of global total population control.
It’s not FUD. Some of us (and by that I mean you) wait for proof that something is wrong before worrying. Others worry by default until there is proof that there isn’t something wrong. You call for proof that IME is a backdoor, I (and @de_dust2 ) call for proof that it isn’t. There isn’t proof available in either direction. Ask yourself why don’t Intel and AMD go out of their way to debunk the serious accusations themselves and get it all over with. They have the source codes and the blueprints, we don’t.
They say these are remote management tools, but for who if the end user doesn’t have access? I can’t even throw money at Intel to make them give me the access key to my own IME. What the fxck is that?