Discussion on Purism

General Discussion
147

This completely depends on your threat model. Please do not force your own threat model on other people.

In what sensible threat model would Heads be more secure than Boot Guard?

I do not trust non-verifiable software written by huge corporations.

This doesn’t say anything. What is the threat model?

but you do not have a right to claim that companies offering me a transparent system fitting to my threat model “cross an ethical line that really shouldn’t be crossed”.

Yes I do. They advertise firmware tamper protection when an attacker has physical access (a.k.a evil maid attacks). The threat is completely clear here, and the goal to defend such attacker is also clear.

Look at their marketing materials:

The Librem Key Makes Tamper Detection Easy – Purism

They spend all this time smearing standard computers and macbooks, when the only thing that doesn’t work even conceptually is their own stuff. Boot Guard + UEFI Secure Boot have plenty of implementation problems in practice, but they are at least not completely bypassable conceptually.

It is also trivial to set up a system more secure than PureBoot on a standard computer. People have already made all of the toolings you need (sbctl, dracut, mkinitcpio, systemd-ukify, systemd-cryptenroll) . All you need to do is custom key enrollment, generate a UKI and pin the encryption key against all the PCRs.

Answer these very simple questions:

What is stopping an attacker from flashing malicious firmware that will just lie about its own measurements on a Librem laptop? (Hint: nothing).

What is stopping such an attack on a normal laptop? (Hint: Boot Guard).
How does it do it? (Hint: using the key fused in the PCH).

The reality of the matter is that Heads cannot provide protection against firmware tampering (and neither does PureBoot) due to the lack of an immutable RoT, while Boot Guard does.

Even for the very specific threat that Purism advertises that it protects people against, their stuff is objectively worse than Boot Guard. They puts people at greater risk of being compromised by an evil maid attack. How is that not unethical?

1 Like
148

[Edit: ignore this post, the forum glitched and duplicated the post].

1 Like
149

I guess it could be preferred in cases when device is sufficiently protected from unauthorized physical access but must be protected from the remote compromise.
Cases:

  1. Machine with proprietary firmware and Intel Boot Guard:
    + Protected from the attacker with physical access if Intel Boot Guard key is not compromised
    - Possible remote compromise if the attacker has Intel Boot Guard key and e.g. LVFS access so it’s possible to just send you malicious firmware update
  2. Machine with open source firmware and without Intel Boot Guard:
    - Unprotected from the attacker with physical access
    + Remote compromise of the firmware is not possible if you build and flash the firmware yourself
  3. Machine with open source firmware signed with your own Intel Boot Guard key:
    + Protected from the attacker with physical access if Intel Boot Guard is not compromised
    + Remote compromise of the firmware is not possible if you build and flash the firmware yourself
1 Like
150

Machine with open source firmware and without Intel Boot Guard:
+ Remote compromise of the firmware is not possible if you build and flash the firmware yourself

This part is wrong and over generalize too much.

  • Companies can sell hardware with open source firmware and sign it with their own key. The threat model would be the same as “Machine with proprietary firmware and Intel Boot Guard:”
  • This is only meaningful if you have an external build machine, and always does external flashing. And then the logical follow up would be, how do you know the build machine is secure?
  • It is only meaningful if you actually audit the code.
  • It depends on the implementation. In the case of PureBoot, you have Heads giving a warning on every firmware/kernel updates. You also don’t have SPI Flash write protection against the OS (On normal laptops, firmware updates are only possible via the UEFI capsule). So what is stopping an attacker who have already gotten into the OS wait for you to do a kernel update and flash their malicious firmware right there and then? You will think the warning is normal, you’ll sign the new boot stuff, and the malware will just gain persistence in the firmware.

Machine with open source firmware signed with your own Intel Boot Guard key:

Would really be nice to have, but is only meaningful if you actually audit the code.

1 Like
151

System76 provides better hardware, firmware maintenance, customer support, and a larger user base than Purism. Also, Purism has been involved in controversial actions, such as scamming clients* System76 has a user base that uses Linux (not just a small portion of Linux that wants to go dark), which makes it attract less attention, as mentioned earlier by some users in this thread. System76 also has Intel ME disabled, coreboot, etc…

What is System76 Open Firmware?

System76 Open Firmware is an open source distribution of firmware utilizing coreboot, EDK2, and System76 firmware applications. System76 Open Firmware can disable the IME, among other features.

*Sources:
Purism ghosts Librem 5 customer, lies about refund policy - avoid this horrible company.
Purism wants me to delete my video exposing their refund scam & delay tactic - answer is no.

You can easily conduct your own research and find many other sources. There are also other companies that manufacture Linux laptops besides System76, such as Tuxedo Computers…

With that being said, I don’t see a single reason to use a Purism laptop.

1 Like
152

Sure, let’s change it like this then:

+ The possibility of a remote compromise of a trusted system by a malicious firmware update is much lower (if not impossible) if the firmware source code is not compromised and you build and flash the firmware yourself

True, that’s why I specifically stated “if you build and flash the firmware yourself”.

The compromise because of a firmware source code (bad design/malicious developers/compromised developers signing keys/etc) applies to a proprietary firmware as well.
But in case of a proprietary firmware there is also an additional possibility of a firmware update binary itself being compromised and not its source code.
So we can say that it lowers the possibility of a compromise and not entirely rule it out (which could be just impossible to achieve).

2 Likes
153

So we can say that it lowers the possibility of a compromise and not entirely rule it out (which could be just impossible to achieve).

Not entirely true either. The problem here is that you are ignoring the possibility of malware gaining persistence in the firmware via a compromised OS.

On normal laptops, there are signature checks via the UEFI update capsule. A compromised OS can’t just magically compromise the firmware without exploiting a vulnerability like LogoFail. Normal laptops also have a “prevent BIOS downgrade” toggle, which will prevent downgrade attacks from the OS provided that it is not a broken implementation like on Lenovo (OEMs like Dell implement this toggle properly).

The likes of the Purism laptops have no such protection. Without an external (and somehow secure, trusted) computer to both build the firmware and do external flashing, you can never know if the firmware on your computer is legit or not. You can’t trust its internal flashing at all.

1 Like
154

I’ve changed the “compromise of a firmware” to the “compromise of a trusted system by a malicious firmware update” specifically to emphasize that the system itself is not compromised and I’m considering the possibility of the trusted system compromise by a malicious firmware update, not the other way around.
Sure, if the system is compromised then you’ll have to reflash the firmware externally with a trusted binary and reinstall the OS from the trusted installation media.
For this you’ll need to have a separate trusted computer that you can use to reflash the firmware externally and download and create OS installation media.
But the same problem applies to the computers with proprietary firmware. You still need to somehow create a trusted installation media.

1 Like
155

But the same problem applies to the computers with proprietary firmware. You still need to somehow create a trusted installation media.

No, thats where you got it wrong. There are signature checks. A compromised OS cannot compromise the firmware without an actual exploit. Normal laptops have SPI Flash write protection, signature checks with the UEFI capsule, Boot Guard, version controls for firmware version downgrade, and Boot Guard fuses.

The Librem has… well, nothing.

Sure, you may need an external computer to create the installation media, but that is significantly easier than reading all of the code of the firmware, building it yourself, then flashing the firmware with a programmer. And that is not even true with the likes of Macbooks - they can redownload the whole OS from Apple using the firmware on their own.

Essentially, the whole “security” strategy is basically giving up on a bunch of real security features for the hypothetical scenario that a user will actually read the firmware code, understand the code, be able to catch sneaky backdoors in there, compile the firmware and do external flashing themselves. And they have to do this in a timely manner too, to get proper updates. It is not realistic. All of this to defend against a hypothetical scenario where the OEM is malicious or that they leak the key and LVFS is malicious.

If anyone wants to argue along the lines of “who needs boot firmware updates”, then I have an easy counter argument too - just turn off the UEFI capsule. How are they gonna compromise you?

1 Like
156

As far as I understand, this is a known issue and being acknowledged, because Flashkeeper is supposed to address that issue.

Acknowledged by @Insurgo at least. Dunno about Purism.

Was mentioned here:

I think it deserves its own forum thread. Created one just now.

2 Likes
157

Dunno about Purism.

They have never acknowledged it. They are still advertising their stuff as being superior to the standard Boot Guard + UEFI Secure Boot setup, and that they can provide protection against physical tampering when standard laptops can’t. I can link a lot more examples of their false marketing.

1 Like
158

@TommyTran732 everything is in nuance and nothing in this world is static. If bootguard was once thought as a good idea by some, it was proven to not be. I would love to see references from Purism saying tampering prevention for Pureboot, since the protections offered are the ones of Heads which Pureboot is a fork, and Heads is about tampering evidence, nothing more unless marketing speech messups written by people not understanding technology.

@TommyTran732 I do not appreciate direct attacks, as all human beings. I do my best under Heads, most of my work having been unpaid and Heads as of today is a story of contributionnism from a lot of experts, enterprises, security enthusiasts and privacy conscious for whom/which bootguard is incompatible, on most basic philosophy principles.

You keep looping around the fact that nothing protects the bootblock and you are right, unless WP pin of SPI is soldered to GND on the motherboard. There would be no problem there if firmware was static : if bootblock code itself under coreboot was not changing over time; but its not the case. So some adapters were made; some funded work has happened to push forward partial region write protection with flashrom, but yet again, the partial region being under SPI chip WP requires the bootblock to not change, and partial region WP encompasses larger than bootblock alone. So some adapters were created to permit a on/off physical switch to hardwire selectable WP to GND. But that doesn’t get traction because people are afraid of soldering, where some adapters got more traction then others for workstations where SPI chips can be replaced with SPI + switch embedded adapter. But that again doesn’t prevent physical access tampering, leving BootGuard to be the only fused, OTP (One Time Programmable) solution, which most experts would advise against, still you refuse to discuss with those experts and continue to claim that because the bootblock could lie about its own measurement, neglecting all other coreboot parts would also need to lie and hardcode measurements, saying that the bootblock itself is not trustworthy and deny measure boot effectiveness. This is an oversimplification.

You denied the fact that to get the firmware version itself, you need physical access to the machine. Then refused to even go Heads qemu/kvm way of testing this without requiring hardware, doing the PoC on emulated platforms that today, require absolutely no hardware whatsoever, outside of your own actual machine, to tinker with, since qemu support now enforces vTPM and canokey (OpenPGP smartcard) so that you could turn your hypothetic exploit into reality for whatever reason that is yours and dodge misunderstanding and get the attention you seem to seek, proving your point outside of stated oversimplification.

The reality of Heads is that having the public key of the user alone, to be injected into a reproducible buklt/downloaded version of to be flashed firmware is not enough to produce a firmware that would pass attestation. The public key was imported into firmware and injected as the keyring inside of Cbfs at re-ownership, and that CBFS file is measured both by the bootblock as part of the payload region under measured boot and by Heads extended security policies. I don’t deny the theoretical possibility of someone being able to tamper with the bootblock, that is not the flaw in your reasoning, on that you are right and always was. The flaw in your reasoning is that to be able to fake measurements, you need physical access to the recovery shell or unlocked powered on machine to pull out at least the logs of cbmem to get the TPM extended PCR measurements from TCPA/TPM event cbmem log, not the final ones stored in TPM PCR as result of multiple extend operations. You seem to miss how things work. To get to the final measurements of the TPM, you need to access from unlocked machine again exposed hashes of regions which are extended to TPM, which only final result is exposed to OS filesystem under /sys. But you won’t get the specific hash measurements of neither the bootblock there nor any other parts needed to extend the TPM event log to arrive to that final measurement, and you cannot simply inject the final desired value into a TPM. Basically, to succeed in your task, you would absolutely need a flash dump of the actual firmware to get imported pub keyring and trustdb state, as it was constructed at Factory reset/re-ownership of the machine and the ROM actually on SPI flash, and to get that, you would also need root privileges or access to Heads recovery shell, which is now guarded optionally under authentication with USB Security dongle. You would have to inject static hash measurements of the measured parts themselves and modify API calls inside of coreboot with hardcoded values for each of them, then modify Heads scripts to also do the same thing with hashes of parts measured to arrive to the same result.

Let’s say you have capabilities to do that; its not just about modifying the bootblock here, but measuring calls for each of the parts involved who do the calls for PCR extend operations to arrive at PCR final status. Of course you could get access to the needed firmware parts measured by opening the machine itself, and get a physical backup of the firmware, but then again you are against Blink comparison and checking for physical intrusion. So ok, someone can take a physical backup of SPI chip and start the non-trivial work of hardcoding hashes in all parts doing read+hash of regions and hardcode those values bypassing read+hash functions, injecting static values, but definitely not a trivial task to repeat for all possible versions of Heads out there with no release since rolling and reproducible builds, where again public key of user is not enough but firmware backup needed to reinject keyring+trustdb+config.user overrides. And then again, you are against keeping the zip file you would have flashed on a seperate USB thumb drive or under /boot (detached signed, trusted) you keep with you at all time and use if you left your laptop behind so that you could flash internally that firmware image that would produce the same remote attestatied state. But yet again you distrust internal flashing and flashrom binary there to be trustworthy and telling that it could also lie to you… Basically you distrust everything not bootguard, but then refuse to look at bootguard successful attacks that actually completely bypassed its security premises, multiple times, with multiple PoC and story repeating itself mostly every years since its inception, with TOCTU attacks, S3 attacks, most of things discovered and whislteblowed to the public by FOSS developers which tries to create alternatives and implore people to distrust Bootguard while showing its flaws to be at least improved upon, which you choose to celebrate in this thread instead.

I don’t understand your reasoning. You choose what you trust by faith here. Nothing else, really. You prefer to trust others and blackbox then your own opsec. You choose… That may be ok for you from your own theoretical background and understandings of buying something new because you accept to lease your machine and rights, but we cannot mix everything like that and expect a consensus or even a beginning of a real technical discussion. This stays too high level and is FUD. Nothing else.

And on that, I would repeat. If I was to hack your laptop @TommyTran732, I would place an implant on your keyboard wires to capture key presses and then access your encrypted content and everything else. That is trivial. I would install that implant once, and come back tomorrow and steal your laptop. Bootguard won’t prevent this. Heads won’t prevent this. Nail polish can prevent this. Proper opsec can prevent this. Blinded faith won’t save you of anything. That is the point.

And believing Bootguard is good is also denial driven, research and each black hat /red team conferences in the past proved this technology should die, but we don’t have anything better, therefore opsec is the sole savior in all cases until we build something better where transfer of ownership is possible and does not prevent improving the ecosystem, with closed source UEFI supply chain being really problematic, which you also prefer to close your eyes upon, voluntarily or not.

This discussion is flawed since its beginning.
If Purism had broken advertisement in the past, were the first to be certified with QubesOS while changing their hardware platform (13v1 Ivy bridge, 13v2 skylake) without renegociating/breaking silently the certification based on hardware revisions, the people working at Purism are not the same as they were back then and Purism contributed to the whole ecosystem in a way that benefited all of it. And they tried, and succeeded. But they cannot change Intel/x86 broken ecosystem. Actually: it seems nobody can. Bootguard is just the last ugly bit of it. And this should be questioned, not celebrated as a one size fits all solution, where it failed for all. Multiple times. You being happy to rent platforms you are supposed to be the sole owner is an interesting statement, to say the least.

I don’t understand nor acknowledge the validity of most of the content of this thread, therefore I limited my participation in it. This conversation is not helpful for anybody. Its not even constructive. In my opinion some valid points you raised were valid, but they were diluted alongside so many wrong statements that it’s impossible to say I agree/disagree. The point is : this is not the place for them, while my intention is not to censor anyone. I read you don’t use QubesOS at some place, trash it, then trash some other reasonably secure premises and then some others some more. What is your agenda?

As FOSS users/contributors, those comments/discussions should turn into actionnable issues so that the problems raised are actually worked on and eventually fixed or enticing collaboration so all eyes are looking at the ideal we want tot attain, not throw who attempts in the dirt forever. You were invited to vPub/DUG, never showed up. Pointed to other places filled with experts to discuss those matter to never show up. To me all of this is as good as a living room conversation with too much booze involved, thinking that that conversation alone will change anything of what happens outside of that room. It won’t.

@TommyTran732 your energy and criticisms are valid in some aspects, but I repeat, not here, not the way you actually do it. At best, you are harming the whole ecosystem instead of bettering it. That’s a choice of yours you can revisit and change at any moment, at your will and convenience. Choose to work for something, not against something. Are you working for Bootguard? It looks like it. Not doing a choice is also doing a choice. And all we do is choose at every moment. I choose where I invest my energy and time to try to change the things i’m against with something i’m for. I wish everyone would do the same, because they could also make that choice and the difference needed. Status quo is not an option. And celebrating a flawed and dying technology should not be part of the options. Not owning the keys should not be an option. Easing owner control/transfer and developing alternatives should be the priority, in the hope that this will get collaboration and traction into replacing this OTP idea which was wrongly implemented at inception and keeps going because of discourses like this one promoting status quo with ideas like “I have enough money to buy a new laptop if keys are leaked” or “I follow the news so everyone should” ideas, where not a single MSI product has been recalled and AFAIK, MSI is in pretty good financial health, not even being publicly ashamed for not protecting their private keys properly outside of network accessible computers, and all journalists I contacted don’t know why they are not bankrupt today. So… Let me ask you. Do you think we are aware of all leaked private keys @TommyTran732 ? Is this denial by choice? Is this denial convenient at best to believe what you believe based on faith and good will?

8 Likes
159

@Insurgo Thank you for highlighting this. I already had the pleasure discussing things with him on twitter/x and reddit. He invalidated all of my sources and when he brought something up (if at all), it’s his own blog or one of his friends.
This dude is nothing but show. The only things i see from him are either some writing on privacyguides, his blog, the different forums or moderation of alot of the biggest privacy communities on the web, in which he sometimes is even admin.

As time goes on and his claims get wilder, i start to think his only goal is to spread FUD.

@TommyTran732 if you think i’m wrong, go ahead, insurgo or novacustom invited you to prove them wrong on a public discussion.

1 Like
160

I find it is extremely weird how you both inflate my credentials are try to take me down in 1 go.

No, I am not an admin anywhere except PrivSec.dev (my own blog). I am a sysadmin in real life. With other projects I am simply a contributor to and nothing more. I am not even involved in PrivacyGuides anymore and I do not wish to be associated with them, since they started posting misinformation/bad advices after I left, just like how they were before I joined.

As time goes on and his claims get wilder, i start to think his only goal is to spread FUD.

What is wild? You are just making stuff up.

insurgo or novacustom invited you to prove them wrong on a public discussion.

I don’t think I need to, since insurgo already agrees that physical attack = compromise of the boot block, and I don’t think novacustom ever makes any claims that it protects against physical attackers either. The only entity doing it here is Purism.

There is some misunderstanding in his reply, I will reply to that and that’s it.

1 Like
161

I would advise keeping things civilized and not put anyone in the dirt. I would advise revising direct attacks on the person. Ideas can be attacked. I have no problem with that. I reacted on calls for “dishonesty”.

Bootguard fused OTP against Dasharo keys will be fused soon as an option. I’m trying to not mix things here. Dasharo is not proprietary while still being UEFI but based on reference code and do not suffer from the same supply chain fiasco proprietary UEFI vendors suffer from. Recent history just showd the same thing with Framework looking to engage an in house firmware developer to stop relying on that mess themselves. My 2 cents here are with hope, not throwing knives.

Dasharo with open source UEFI implementation targeting float of computers that will be updated with fwupd even under QubesOS is desirable. But I keep caution and hope 3mdeb will air gap their pirvate keys so MSI similar story won’t dirt them by a leaked key years from now. OTP is One Time Programmable fuses. If Dasharo key leaks, that would be a disaster for the open source firmware ecosystem and I only hope they are doing everything in their power to properly secure that signing key, and I have most hopes they won’t cooperate with government agencies that now will be able to pay big bucks trying to buy their honesty. All of this is possible with Bootguard. That’s a fact and that is all there is. Bootguard is at best convenient vs secure, where Joanna again puts this vocabulary in our heads really hardly and reationally: We don’t like “Secure” marketing words. All there is now is reasonably secure and trustworthy, where of course everyone has the right to choose convenience over trustworthiness, transparency and auditability and transfer of ownership.

Please don’t expect too much of me answering again here. Searching for my past posts should be enough.

2 Likes
162

@TommyTran732 that is not what I said. Actually I said your understanding and reasoning goes way too simplistic in my previous post and showed, theoretically where a lot of other things would need to also be tampered with, but you seem to selectively choose what you want to believe, is what I also said.

Please do a PoC and leave me out of this. 7 years we wait for a PoC. Yes there is a theoritical flaw, but don’t bring my reasoning and explanations to meet your simplistic “bootblock could lie” as agreeing with you on things I said multiple times disagreeing with you with already. This is looping is all I tried to show. We need a Bootguard replacement is what I said. That’s all. Leaving this discussion be, now. I choose my battles, this is not one of them. Writing more in this forum didn’t prove to be useful. This thread is not my battle and I welcome Purism people to represent themselves. I only talk as Heads maintainer here (and my sole opinions as tlaurion, as a person). And invite the discussions to happen where helpful. The more I say the more people will twist my words, history also showed. Time for me to learn as well and economize my energies to where they matter.

3 Likes
163

You’re already doing it to yourself by not providing any PoC after making claims. Also this is not our first encounter and you were always like that.

Of course you don’t. What’s holding you back? Pretty weird how you love taking those controversial takes and then when it’s time to deliver you back off. You even completely ignored their invitation to the public debate.

1 Like
164

I would love to see references from Purism saying tampering prevention for Pureboot, since the protections offered are the ones of Heads which Pureboot is a fork, and Heads is about tampering evidence, nothing more unless marketing speech messups written by people not understanding technology.

They advertise detection against physical attack with Heads. There are plenty of places where they do it, but let’s start with this YouTube video:

That is Kyle, their Chief Security Office then and President now. Not exactly marketing people.

Here is the PureBoot page they linked in their recent marketing material: PureBoot, the High Security Boot Process – Purism

In this second link, they advertise protection against malware compromising the firmware.

So we have at minimum 2 security properties being advertised here.

So the first one, against physical attacks, it clearly cannot provide that protection. You never advertised such things, so of course I am not going to hold it against you or Heads. The problem here is that they can be pwned in just 1 go, the very thing they advertised that they can defend against in that video. You absolutely do not need to defend them, but this is the type of thing they advertise. This is the type of unethical marketing I am talking about. It has absolutely nothing to do with the whole “getting certified by Qubes then changing the hardware”. That is not what I am talking about.

With Boot Guard, depending on the OS configuration, I can do a full combo of TPM + PIN + FIDO2 if I wanted to. This is already possible. You’d need at least 3 evil maid attacks, or 2 evil maid attacks + stealing the FIDO2 key. It is much stronger.

Now, to the second security property, against malware gaining persistence.

You denied the fact that to get the firmware version itself, you need physical access to the machine.

This is the misunderstanding with your post. If I have compromised the OS, I do not need to get your firmware version or lie about the measurements.

The property with Heads is that every kernel update, the user will see a red warning, that is expected. So that can be abused by the attacker.

They can just make a dnf/apt/pacman hook or whatever to do internal flashing when the kernel is being updated. They can wait for a kernel update to do internal flashing of their firmware at the same time. The user will see a red warning, think its normal, opt to sign the new stuff the warning goes away, and that is the end of it. The malware is now persistent in the firmware until someone actually take a dump of the firmware with an external computer and check it.

These are 2 completely scenarios.

Against the first one, I do not see this ever getting better than having an immutable RoT. It doesn’t have to be Boot Guard, it can be AMD PSB or whatever the new Snapdragon laptops use. If they just acknowledge that it is a problem like you do and retract all of the false marketing, that would be one thing. But in reality they are just lying. I burnt $2000 on a Librem 14 expecting better protection than the Latitudes/Precisions and I got a much worse product. I also wish I didn’t fall for their nonsense and believe that normal laptops do not have protection.

Against the second attack - it can be solved with a functioning physical write protection toggle. Guess what? They don’t even have it right now. They have been selling laptops and making these claims for years now, where is the EEPROM write protection? The Librem 14 I bought is an insecure mess - it can’t even defend itself against this.

Please do a PoC and leave me out of this. 7 years we wait for a PoC. Yes there is a theoritical flaw, but don’t bring my reasoning and explanations to meet your simplistic “bootblock could lie” as agreeing with you on things I said multiple times disagreeing with you with already.

You said multiple times that physical attacks = game over. Do you really want a PoC just to prove something you already know? The logic isn’t there.

With the second attack, I can just write a package manager hook. Which one do you want? :wink:

Let’s try with pacman, its just something along these lines:

/etc/pacman.d/hooks/99-malware.hook

[Trigger]
Type = Package
Operation = Upgrade
Target = linux

[Action]
Description = Kapoot
When = PostTransaction
Exec = /path/to/intenal/flash/script.sh

Absolutely no fancy measurement bypass needed! There, that took me about 1 minute looking up how to make a pacman hook.

Even with a physical toggle to defend against the second attack, it is extremely annoying and not realistic to expect to do this, especially on a fleet.

Every firmware update on a laptop = Taking the bottom cover off, turning WP off, get a somehow trusted computer to build the firmware and do external flashing, turning WP on, putting the bottom cover back on. If you wanna do the nail polish stuff, that’s even extra work. And this excercise only means something if the user actually reads the source code and audit everything themselves, otherwise its still just blind trust. This is just not realistic.

Oh, and Purism sells servers with PureBoot too. Good luck doing this business with a whole server rack, or a whole suite.

I have 0 clue why ou keep bringing up the USB strategy. If the firmware is already malicious, why are you even trying to do internal flashing? The point is not to find out if you have been pwned after the fact, the point is to prevent booting into the compromised environment so people don’t get pwned in the first place.

At best, you are harming the whole ecosystem instead of bettering it.

How? Just because I call out obvious lies by a company regarding security properties?

Are you working for Bootguard? It looks like it.

No. I just look for the most secure and maintainable solution, and I set up stuff in my OS to work with it for as much protection possible. It just so happens that I keep saying Boot Guard because it is the easiest. The same logic applies for AMD PSB or whatever with an immutable RoT.

Status quo is not an option.

Too bad, unless there is a better idea that immutable RoT, I am sticking with it. This applies to any kind of device I have - my several laptops, my fleet of servers, and my phones.

This one promoting status quo with ideas like “I have enough money to buy a new laptop if keys are leaked”.

Because it is the most realistic thing to do.

I follow the news so everyone should

No, I just follow the news in general. And I was never vulnerable to the leaked PK stuff. Standard practice with me is rolling my own PK key. I recommend what is objectively the best solution to other people, I am not tied to a particular product or ideology. I certainly wouldn’t recommend an objectively less secure product to other people and promoting it cuz “muh freedom”.

Do you think we are aware of all leaked private keys

Of course not. But then the question is what happens with the leaked keys?

In the case of the leaked PK you originally linked - the impact is 0 if you follow the practice of doing your own PK enrollment anyways. If you buy a Secured-core laptop (I do), there is not ever a need to trust the OptionROMs with your KEK or DB. So you can just have stuff signed by your key in the DB and that’s it. Idk what the problem is.

In the case of MSI Boot Guard key leaks, it is the unfortunate case that there is no mitigation. But guess what?

  • Against the first attack, it is only less effort for the attacker to pwn it. But otherwise, it is the same as Heads, it can be compromised in 1 go.
  • Against the second attack, it fair better than the Librem laptops still. Yes, you need to follow the news, but the mitigation is just disabling the UEFI update capsule. Download the firmware updates from another computer and use the firmare’s internal update tool. The SPI flash should not be directly writable. At least, that is not the case with Dell/Lenovo. I don’t have an MSI laptop anymore so I can’t check.

Anyhow, for vendors like MSI, I just blacklist them altogether as their firmware is super buggy anyways, on top of how the Boot Guard keys situation was handled.

1 Like
165

@TommyTran732 Alright, the M$ fanservice again. How much do they pay you?

Let’s cut to the chase. You’re scared endlessly by the fact that your reputation gets publicly destroyed within minutes, because the only thing you’re doing is poking in the blue.

1 Like
166

Alright, the M$ fanservice again. How much do they pay you?

Where is the fanservice?

You’re scared endlessly by the fact that your reputation gets publicly destroyed within minutes, because the only thing you’re doing is poking in the blue.

LMAO are you serious right now? I explained in detail the 2 attacks, and I already wrote one because it is so easy and could be done within a minute. The other one takes more work and I don’t have the time and energy to do it right now.

You are literally just turning your head off and can’t even understand a single technical argument. Like seriously, do you have anything to say about the epic pacman hook?

1 Like