Why do Librem laptops ship with Manufacturing Mode enabled?

Hardware
1

After CVE-2018-4251, this is a huge potential security risk.



https://trmm.net/Bootguard

Apple was quick to fix it last year with an urgent patch. By urgent I mean one that
goes to the next update without delays or next major version, which makes it very
high severity. Also

The attack is rather simple, with this mode on, an attacker can reflash any BIOS region
including Bootguard the ME region with INTEL-SA-00086, and basically persist on the machine
forever, or unless the user reflashes the chip with a physical SPI SOIC-8 programmer.

Do you plan to address this, or at least support locking this as part of with coreboot_util,
while first fusing your (Purism) OEM Public Key Hash to the flash? So that it won’t break
signed BIOS updates to Coreboot or Heads.
Alternatively it will be possible to write a manual of how a user can become his “Own OEM”,
signing BIOS images himself after compilation, but since this is not an easy process I doubt
most users will benefit from that.

I am aware of this “policy”:

Remember, once FPFs such as these are set, they become immutable–permanently fused and impossible to change. The essential part here is to leave them unfused or to fuse them in a configuration that gives the end user control, supporting the best security, privacy, and freedom for users.

Purism’s policy is to ship these unfused, allowing a user maximum control. In the process, we are ensuring that users can use their Purism devices with the ME neutralized and disabled.

In reality, it is almost like saying:
By default we ship our devices without a password for maximum control. This gives the user more freedom etc.
But since most users are unaware of this, actually shipping it “insecure by default” is what makes it not TOFU.

2

Could you please outline the steps an attacker would have to follow?

Could you please elaborate how this affects the security level of those who use PureBoot and of those who don’t?

2 Likes
3

Any kind of physical or remote attack which will allow running code in ring0 (root) on the machine.
Supply chain attacks (during shipping) or when someone tampers with your machine for example during
a border control are the most common methods, and remote exploit 0day if you are special enough.
But not something from the science fiction world, all major countries have these capabilities.

Pureboot is just PoC / beta, and requires additional hardware (Librem key, USB key) and the instructions
are a YMMV mess. I don’t know how many users actually have it enabled.
The scope of this report is about current batch of hardware, and it’s default configuration, not future
“nice to have” mitigations. When those become available, at least an option would be present for the user.
All that of course, if you installed Pureboot on a previously clean machine. That’s a tinfoil hat stuff, but
if your machine is already infected you cannot fully trust flashing it with software methods anymore.

Probably in the future they will decide to ship it with Pureboot + MM disabled from factory, and future
upgrades are signed with their OEM key. That would be the most secure setup.
Just like major vendors do BIOS updates these days, you can’t just flash any custom compiled code
to your own BIOS from software, that will be a security disaster.

4

Well, you didn’t really go into the details I hoped you would.
I assume we can agree that physical access (before fully activating PureBoot) is always a dangerous thing, independent of this case.

On the remote attack vector I’m not so sure. Maybe I got that wrong.
Are you sure that the attack outlined by the article is possible with the stripped-down version of ME that Purism ships?
First, at the point where the OS takes over, the ME co-processor is in HALT state AFAIK, so it can’t react to commands.
In addition, the command discovered in the disassembly is likely not present in (or should be removed from) the image Purism ships.

So, you say you’d need a 0day, to gain ring0 access.
At the point where you gain root access, you can already

  • install a backdoor on OS level
  • install a backdoor on coreboot level

So, what do you gain by re-flashing a vulnerable ME, only to fuse a fuse?
I think you’d then have the choice to brick a device instead of spying on it.
Monetarily worse, privacy-wise better.

EDIT

Purism would view this as a freedom bug, not a feature. TPM + heads are meant to give you the full control over which firmware you want to trust, instead of having to use one that is approved by a “authority”.

I’m uncertain whether MM is necessary to update the ME image.
But if so, you’d have the direct answer to your original qustion “Why ship with MM enabled?”
/EDIT

It’s a bit confusing how, in this context, you disregard PureBoot. Yes, needs additional hardware.
Either you care about such high-profile attacks, then you want it, or you you don’t really see yourself as a potential target and you don’t care.

If you want a reliable answer, I guess it would help to tag somebody more knowledgeable than the two of us.

5

You got it wrong, there is nothing to do with ME here, it’s just one of the examples of how to maintain persistence. Just like when you flash a ME-disabled firmware, you can flash an image with it enabled.
Or enable an old version of it with your own configuration. Such as exactly what Intel-00086 is about.

Persistence is the key here. Nobody cares about OS level backdoor that you can wipe with OS reinstall.
If it was that simple it won’t be that critical for Apple, for example to roll it as urgent patch.

This doesn’t make any sense from a security standpoint. Same as a vendor will ship a rooted Android device
from the factory, and claim it was done to give the user more control and freedom, which it will, but also open
a huge security hole most users are unaware of.

I disregard Pureboot because it’s not something currently available. And this is not something that can help
you in case of already tampered machine. Some people here don’t know basic Linux commands and don’t
expect to be security experts to be secure, that’s why they pay a very premium price for that “freedom”. Just
like any other premium vendor won’t tell you there is a very technical PoC beta currently available, it’s not a
thing you can discuss now as a general solution. There is a concept called Trust On First Use which Librem laptops cannot be considered as at this point. Any other claim would be masking a security hole as a freedom
or privacy “feature”.
What is ironic is that a computer that is supposed to be more resistant to attacks because of a free BIOS, and
a clean ME, is actually more prone to them in the first place because of this policy.

6

actually no. they do have a very transparent roadmap laid out pretty clearly. no one actually thinks it’s a 100% buletproof machine. not even the newbies.

and even when they actually reach the point of a perfect machine - it would still be insecure because nothing is unbreackable.

the librem machines are the only modern machines that come with a dedicated gnu/linux OS for the hardware preinstalled thus they have that premium.

3 Likes
7

Sorry for assuming you actually read the article before linking it here.

You did not care to explain how the vulnerability gives you unexpectedly more power than the coreboot-update utility Purism provides.

So, basically you referenced a CVE for dramatic effect.

Nothing really can.
But when PureBoot leaves beta (by shipping devices in separate packages), it can at least give you the same level of trust that a locked-down firmware (with source and reproducible builds available) gives you, while retaining freedom.

But the main point you’re trying to make is that Purism should

  • not give users the freedom of flashing firmware and lock it down, or at least
  • warn the user that the knife might have sharp edges and provide an easy way to make it dull

The first will not happen, but the second might be worth consideration.

2 Likes
8

Sorry to crash your party but it’s not. System76 does it, ThinkPenguin does it.

Flashing a malicious ME payload, such as one that will allow remote access is one of the scenarios.
Watch what you can do, as:

And stop talking about Pureboot as some kind of a silver bullet, Purism had nothing to do with Heads,
and if you so much like Tramell’s work, read his (correct) tips for further hardware hardening:

Soldering jumpers on WP# pins, setting BP bits, epoxy blobs.

Yes, exactly, not leaving an additional software attack surface as a “freedom feature”.

9

Even if Purism shipped the machine with a WP flash chip, who’s to prevent a skilled attacker from simply removing any hardware protection mechanisms, flashing their own firmware and putting the temper protection back? With enough dedication, even a epoxy blobbed chip can be desoldered and a new one put on complete with a new epoxy blob.
It would be better than shipping without WP as it protects the end user from software flashing attacks. The mobo could have a hardware button or jumper to disable WP for the short time the user wants to do a firmware update. Still, if the software is compromised at that time, the flash image could be altered as it’s being written to the chip. One could boot from a live USB drive with only the flashing tools on it to protect from that, and ideally the flashing disk would be created on a different machine. But for a start, enabling WP on shipped machines and having a button to disable WP before flashing would be an advantage.
I’m not sure if there’s a way for Purism to load their own signing keys into the processor itself, I thnk only Intel and OEMs have a way to do that. But then only binary firmwares supplied by Purism could be used, and that has its own issues of one single point of compromise at Purism.

10

That’s why they won’t do it.

Read how PureBoot works. For this, you would need to have physical access to both, the laptop and the key.
That’s why they intend to ship them separately.

Well researched, as always.

1 Like
11

Yes, besides ‘git clone’ and a nice blog post about how they made it possible. Apparently they are good at that.

12

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.

13

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

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
14

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
15

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 …

16

I didn’t know a vulnerability report will end up a fanboy party off topic. Enjoy.

17

A “vulnerability report” :rofl:

It’s really hard to take somebody serious who

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
18

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
19

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?

20

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