I forgot about the Key. That’s much better. Still, they could both get intercepted by e.g. customs at the destination country. You’d need to ship the Key with a different shipping provider, preferably disguised as normal mail from someone else, in a normal envelope so customs wouldn’t intercept it.
You’re on to something big I think.
Leak it to the press how you discovered that a git clone disproves collaboration and financial compensation.
Hudson will be furious when he discovers how his good name was used without him ever knowing.
How long has this fraud been going on before you opened our eyes? Two years?
Wow. 
I’m still undecided whether you’re just trolling or you’re an actual customer who has no problem to damage the reputation of a company for being too lazy to do actual research.
But the way you avoid giving details and tagging a knowledgeable staffer somehow hints you’re more interested in heated discussion than factual answers.
4 Likes
Precisely. Well said @Caliga.
Furthermore, a small aside partially relevant to this thread based on a previous comment, Purism is not trying to be the ONLY company doing anything. They hope to spur a host of competition that helps to champion their goals.
2 Likes
they do but not like Purism does it. also librem 5. also PureOs. also PhoSh. also hardware switches. also anything that helps to further the gnu/linux ecosystem and bring software freedom security and privacy into the general public attention.
as Caliga says - what are you really trying to say ? would it be better if we didn’t buy Purism goods at all ? or if Purism didn’t exist at all …
I didn’t know a vulnerability report will end up a fanboy party off topic. Enjoy.
A “vulnerability report” 
It’s really hard to take somebody serious who
- says an ME-related CVE is not ME-related
- claims to own the truth on Wire vs. Matrix
- proves fraud with a git clone
- thinks airplane mode is as good as a kill switch
- says others implied that Purism claims to make unhackable devices
- counters arguments with ad-hominems
You off-topic yourself by not following up on attempts to actually answer the question you posed.
In case you forgot, your question was:
Why do Librem laptops ship with Manufacturing Mode enabled?
tried to bring you back on topic:
3 Likes
And this is where it becomes clear you’re not looking to have an actual conversation on any topic.
It doesn’t take much effort to look at the commits / pull requests for coreboot, Heads, etc and see that while Purism maintains our own repos for many projects out of convenience, we also push as much of our work back upstream as possible, and work with closely with those projects to advance common goals (the UI Interface for Heads was done by Purism, eg). Claiming as you do that we simply clone and blog is dishonest at best.
5 Likes
Why, because I am not talking like some unpaid fanatic shills around here?
This is my right to have this opinion and this by no means changes anyhow the idea of this topic.
You know exactly what I mean by saying that, it’s enough to take a look at most Pure[name] rebrands
to know that just changing a few minor things and changing the project name is also dishonest at best.
Sometimes it can make people think that Purism is entirely behind the development - look how many
people around here say “Wow, they have their own OS, they have their own Browser, they have their
own name it” kind of thing, which makes me smile.
Care to address the elephant in the room?
you have the right to your own opinion, you don’t have the right to your own facts. Your facts are wrong about Heads, which is specifically what I was addressing, given the topic of this conversion
To the best of my knowledge, a disabled/neutered ME is not exploitable in the ways described in PT’s blog post linked in the OP, because there is no way to interact with it from userland, even with escalation. There’s no PCI interface, no HECI interface, and no way for FPT or any of the other tools mentioned to query or change any settings of the ME (I verified this on one my my Librems earlier today). One would need to flash custom (AP) firmware which does not enable the HAP bit, enables the ME/HECI interface, and which contains non-neutered ME firmware for any of this to be an issue. And if an attacker has managed to flash custom firmware on your device, then the ME Manufacturing Mode not being closed isn’t really your problem.
Fusing the OEM pubkey hash isn’t a feature available on shipped Librem laptops, notice the article is referring to specific newer platforms on which this feature was added. We also don’t do signed firmware updates, because that would prevent the user from running their own firmware on the device (vs Purism’s official release).
4 Likes
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.