Why do Librem laptops ship with Manufacturing Mode enabled?

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 :sunglasses:

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. :grin:

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 :rofl:

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:

  1. attacker gets remote root
  2. he replaces the firmware with its own
  3. fuses the processor so it will only accept firmware signed with attacker’s key
  4. 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 :slight_smile: 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 :slight_smile:

Provide real arguments if you can/want.