Next time, try with less arrogance.
It will pay out in the long run. Trust me.
1 Like
Again, as I explained, an open Manufacturing Mode has nothing to do with disabled ME. Yes, the CVE
and technique are regarding ME, but we will touch it later.
The idea behind the attack is to flash a new BIOS image, just like one would do from:
So far so good?
Now, instead of flashing your version of clean_me (with -S) flag, I take the full skl/kbl image +pre-2018 ME and flash it along. By that we both enable ME and downgrade it to the vulnerable version, including old Microcode.
So we have now a malicious BIOS+enabled exploitable ME+exploitable pre Spectre/Meltdown microcode.
If you want to leave ME out of this question, fine, just a custom malicious BIOS+exploitable microcode.
Less persistence but at least without the ME confusion.
The attack surface here is not ME itself, we just may use ME later for persistence and other malicious things.
A vector like this means leaving the BIOS flashable from any privileged software in the OS, when the attacker
can flash a malicious BIOS and then fuse the chip with the malicious code - similar to ifdtool --lock.
After that the user is left without an option to install a clean Coreboot.
Remember that when you provide the user with a simple way of flashing a clean ME and blob free BIOS,
which is good and not many vendors offer it, fair enough, you also leave a way for the attacker to
flash anything bad and with unfused chip (MM) itâs a race of who will persist first.
Here is when freedom is a sword with two sides, and it shouldnât be that way.
Itâs a weird way of saying âsorry for needlessly complicating the matter with an unrelated vulnerability reportâ, but Iâll take it.
Youâre now basically saying what I said in post #4:
@Caliga
You definitely showed that you have no capability of understanding how to chain attacks and make PoCs.
Calling an attack scenario unrelated because itâs part of the chain shows some level of incompetence.
We understand it, and your opinion here is largely irrelevant, itâs for the real devs and not forum celebrities.
Keep it coming, I begin to enjoy 
When I asked for that chain in #2, it didnât really look like you already had one in mind.
Now you paraphrased the one I had in #4, which actually contains your CVE trick.
Look. If somebody gains root access, youâre ******* DOOMED.
And if the machine grants you the right to overwrite the BIOS, you OWN the boot process and the CPU firmware already.
Itâs really cute to have a trick to do some restricted stuff from OS level, but when youâre already in god mode, itâs really just sugar coating.
As you have to reboot anyway after flashing the ME enabled firmware, you can execute whatever you want during boot time, before EOP.
After you executed this already almighty power, you can then go ahead and use the CVE to âŚ
an attacker who sends these two HECI commands opens the ME region and can write arbitrary data there, without having to reset the platform as a whole.
Cool. After gaining god mode and rebooting, I can then do god mode stuff without rebootingâŚ
Sorry for stating the obvious. You real devs of course knew that all the way long. 
1 Like
No. Without persistence or common malware attacks, you can reimage your OS and use it again.
Are you trying hard to make fun of yourself with such claims? Do you even know what persistence is?
Rootkits? Why even bother protecting the BIOS is important? If all we need is just to reformat the OS and
be safe again? I suggest you start reading because such claims make you sound very ridiculous among the tech community. Burying the head in the sand and dismissing problems is easier than solving them.
You still fail to understand the concept behind the entire process, at which point it stopped making any sense
wasting my time to explain it to you.
Wow, itâs getting better 
Did I win, Mr. Quizmaster?
@s3ns0r, @Caliga: Iâve already forgotten what this thread is about. You two could do well to end it right here. Just cut it off, please.
1 Like
Sorry. Summary.
- Purism ships computers where the (root) user/attacker has all privileges he possibly can have, including the privilege to make arbitrary, permanent changes to the firmware and even irrevocably alter some CPU settings.
This, obviously, includes the power to install rootkits below the OS level. - Apple sells computers where these privileges are reserved to Apple. The CVE lets the user/attacker escalate them.
I can see one potentially problematic scenario here:
- attacker gets remote root
- he replaces the firmware with its own
- fuses the processor so it will only accept firmware signed with attackerâs key
- blackamails with âpay me, or your machine will turn itself off after a weekâ.
If point 3. is possible entirely via software, then it needs to be addressed somehow - as it potentially makes computer remotely and irreversibly brickable. But is it? I canât tell, I donât know how the processor fuses are manipulated.
1 Like
Exacty, it should be addressed by an option for locking Manufacturing Mode with ifdtool --lock
during or after the coreboot_utility.sh execution.
A signed binary firmware from Purism should be the default way to go for most, above 90% of users.
Razer, the premium gaming laptop manufacturer thought itâs also a good idea to ship with MM=on to allow
overclockers do some custom BIOS mods. But they quickly changed their approach as I linked above.
A small portion of people who like to compile their own BIOS should be notified about the risks.
Point 3 is correct. This is how an attacker can make a persistent non software flashable BIOS (future flashable via SPI hardware only so nothing new here).
Point 4 is not the real concern here. Such sophisticated attack is not going to justify itself for some small ransom.
That will be equivalent to breaking into a bank and asking the staff for some snacks.
A nation state/business intelligence/corporate spying are the threat actors in such cases, not random script
kiddie cyber criminals that encrypt your files and ask for a ransom.
A more valid scenario is that an activist, a journalist or a developer would become a target, where the rootkit
module is staying persistent in ring -2. So even an OS like Qubes can not fully protect such user.
And if the attacker has root, what is stopping him form doing ifdtool --unlock?
Let me clarify here the point 3: It is about field programmable fuses inside CPU. Once they are altered to the attackers tastes, the game is over and the CPU is garbage - it will refuse to run with your firmware even if you flash it somehow.
My question: is remote root access enough to manipulate FPFâs on the CPU, or would the attacker need a physical access? If the former, then it is a serious problem. If the latter, then not really, as no permanent damage to equipment can be done and coreboot/os-level security measures remain adequate.
This can only be done via hardware SPI connected to SOIC8 clip on the BIOS chip. Itâs not a software ifdtool flash command.
You cannot lock and unlock âat willâ a fused, locked chip, you can only lock once, and then to unlock via hardware, to a point where it will stay unlocked. Thatâs how all the people who use vanilla me_cleaner flash their locked BIOSes.
The attacker does NOT need a physical access for what I described. Obviously with a physical access you
can do any of that and it will not be considered a vulnerability.
TL;DR:
An enabled Manufacturing Mode allows FPF manipulation via software. Thatâs all.
Any claim that it provides the user more freedom, is same as providing someone a âfreedomâ with a loaded gun and the safety pin off. MM is the safety pin.
you seem to repeat this âfreedomâ term quite frequently in relation to what/how purism does things (you frequently refer to the ring -2) . itâs like saying âmake a choice. proprietary attack vector or âopenâ atack vectorâ and constructing your arguments to somehow logically lead to âclosed/locked/unfreeâ is preferable to âopen/unlocked/freeâ. basically saying pick-your-poison.
3 Likes
Yes, because this is the most common argument here some misinformed people here use in order
to counter my claims and kind of bash me personally 
that it just should be like that. Well, if you want
a secure device, it shouldnât. Whatâs the benefit of all that free software if itâs more risky (and it is at the
current state) to use more than a proprietary BIOS? A point for consideration.
what are you complaining for then ? the majority of free software users DO run a proprietary BIOS ⌠but that is because they have little or NO idea about the fact that lower than OS rings do exist. the whole computer is just a magic box that somehow makes life easier/convenient
we are a LONG way from reaching a fully free universal software/infrastructure scenario.
while weâre at it why donât we also talk about the GPU (a blacker box compared to a neudered Intel ME chip)
1 Like
⌠and the (main) CPU itself.
The tamper-evident features in the PureBoot firmware will alert you if anyone tries to reflash the ME to add back vulnerable code, and then exploit it. Anyone who would do that would have an easier time just compromising the firmware itself, of course.
In either case PureBoot would detect the tampering the next time you boot and alert you to it. Locking down Manufacturing Mode would at best only protect someone from this hypothetical attack where an attacker with root would essentially brick your machine so while you could detect the tampering, youâd have to have a hardware flasher to undo it (or ship it back to Purism so we would do it for you).
Our approach gives users more freedom as they arenât required to trust us at Purism (or our signing keys) to have a safe boot process. You can easily replace any PureBoot keys with any keys of your choice at any time, and when we start offering it as a factory-installed option, you can easily replace the factory-installed keys with yours the moment you get the hardware.
Detecting tampering, but allowing the user to still own the hardware and do whatever they want to do with it, is a completely different approach than most vendors, who can only offer you the choice of trusting them (and their key management) 100%, or otherwise disable their security and have no protection.
8 Likes
If you want your arguments to be taken seriously, you have to be genuine and truthful in your accusations. It wouldnât take very much effort to see all of our contributions to Heads.
As one of the main contributors to Heads these days I take offense at your dismissing my work as a âgit clone and a nice blog postâ and it leads me to believe you donât intend for anyone to take you seriously and are just trolling.
10 Likes
Oh come on really? I expected better from a CTO. Now ask your technical guys to demo the
actual attack to you and your board, or actually I
can wait the acceptable 30 days and publish in on reddit and all those places you advertise at.
Donât take my attitude as a consideration about
this or any other vulnerability. Yes I like to smack
them right in the face of the vendor without much
political correctness. Does it make the real risk
lower? no, it makes you adressing me for some reason instead
Provide real arguments if you can/want.