Trying to do this all from first principles, so:
* A freedom-respecting computer should never prevent a user from running software they want to run
But also:
* A safety-respecting computer should never allow someone other than the user to run software that acts against the user
There's no inherent conflict here - the user should be allowed to run whatever they want, someone who isn't the user shouldn't. But how do we tell the difference?
Peter Van Eynde reshared this.
Matthew Garrett
in reply to Matthew Garrett • • •The point of secure boot is to prevent early stages of the boot process from being compromised in such a way that it's impossible to build any other OS-level security policy. For now let's assume that that's something the user wants[1] - this implies that from a safety perspective the computer should be able to prevent a malicious individual from subverting that
[1] It's perfectly reasonable to disagree about whether this is a sensible default, let's come back to that later.
Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Matthew Garrett • • •Someone is inevitably going to say "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety" and to those people I say I hope you use precisely zero websites that have enforced password requirements
(also the thing people keep forgetting is "essential liberty" - if I can give up freedom for safety while knowing I can restore that freedom at any time by reconfiguring my system, I don't think any essential freedom has been given up)
Elena ``of Valhalla'' reshared this.
Glyph
in reply to Matthew Garrett • • •KevinOfComputer
in reply to Matthew Garrett • • •Andreas Sikkema
in reply to Matthew Garrett • • •Rob Isaac
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Rob Isaac • • •pl
in reply to Matthew Garrett • • •Eli the Bearded
in reply to Matthew Garrett • • •I think the tension comes from computers being extremely literal when the naïve user expects them to be smart. All of the smarts is a pile of heuristic rules coded by people who haven't thought of everything.
Nefarious people find loopholes in the literal rules. Less technical people just think the smart computers should be able to figure it out. More sophisticated users don't realize the heuristic to hard and fast rule ratio.
gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Furthermore, there is no easy way to revoke or replace the compromised keys. MSI does not have an automated patching process or key revocation capabilities like some larger hardware makers do. This means that MSI would have to manually update each affected device with new keys and firmware. This could take a long time and leave many devices vulnerable in the meantime.
Intel is aware of these reports and actively investigating. However, it should be noted that Intel Boot Guard OEM keys are generated by the system manufacturer, not by Intel (tomsguide.com). Therefore, Intel may not have much control over how these keys are managed or secured by its partners.
uefi and secure boot are problems that need to be addressed but it is not going to happen - the problems will persist - and they will persist because they are convenient to gain low level access but also because of complexity and tech debt - it is an unfolding story that will have more twists and turns but maybe some progress will be made eventually - for the time being and near future there will be no easy solution - it is a big mess
Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •babak@G750JHA ~/Desktop $ binwalk -Me ./Cottonelle.bin
Scan Time: 2016-06-18 23:19:58
Target File: /home/ubuntu/babak/Desktop/Cottonelle.bin
MD5 Checksum: f330370ed549c30bb301b42e7363ce32
Signatures: 345
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
16560 0x40B0 PEM RSA private key
18608 0x48B0 PEM certificate
20484 0x5004 PEM certificate
32944 0x80B0 PEM RSA private key
34992 0x88B0 PEM certificate
36868 0x9004 PEM certificate
301529 0x499D9 Certificate in DER format (x509 v3), header length: 4, sequence length: 177
414737 0x65411 Boot section Start 0x42423242 End 0x0
414741 0x65415 Boot section Start 0x0 End 0x0
414911 0x654BF Boot section Start 0x3C42 End 0x0
414915 0x654C3 Boot section Start 0x0 End 0x0
415370 0x6568A Boot section Start 0x14 End 0x30000
518776 0x7EA78 PEM RSA private key
520488 0x7F128 PEM certificate
521984 0x7F700 PEM certificate
531224 0x81B18 HTML document header
532867 0x82183 HTML document footer
532876 0x8218C HTML document header
533428 0x823B4 HTML document footer
533440 0x823C0 JPEG image data, JFIF standard 1.01
549524 0x86294 SHA256 hash constants, little endian
550196 0x86534 PEM RSA private key
550592 0x866C0 PEM certificate
788672 0xC08C0 Copyright string: "Copyright (c) 1996-2011 Express Logic Inc. * NetX Cortex-M3/GNU Version G5.4.5.0 SN: 23451-108-05
Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •Matthew Garrett
in reply to Matthew Garrett • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •Matthew Garrett
in reply to Matthew Garrett • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •(2) signed binaries aren't encrypted, you can still examine everything they do
(3) memory protection has absolutely nothing to do with this, UEFI doesn't enforce it so you can dump the entire contents of physical RAM
(4) this is one of the topics I am absolutely an expert in, if you think I'm wrong here then you're probably following the wrong person
gary
in reply to Matthew Garrett • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •@gary_alderson No, it doesn't. Secure boot is inherently about signed boot chains. Measured boot avoids that requirement.
Look, I don't mean to be a dick, but you're making very confident assertions to someone who's been stuck working on this shit for over a decade. You should maybe consider the possibility that you're either misinformed or have misinterpreted something here. I can promise you that I, and many others, have examined the Microsoft-signed code without special powers.
gary
in reply to Matthew Garrett • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •techtarget.com/searchsecurity/…
Eclypsium calls out Microsoft over bootloader security woes
Rob Wright (TechTarget)Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Even though Microsoft has a huge presence in the UEFI Secure Boot ecosystem since it established its own CA in 2011, Shkatov said the company hasn't provided much visibility of its bootloaders to the infosec community.
"There are X amount of bootloaders in the world signed by Microsoft since 2011. There's only one organization that knows how many bootloaders and which versions are out there," he said. "And there are exactly zero external organizations that they're willing to share that information with."
gary
in reply to gary • • •Matthew Garrett
in reply to gary • • •gary
in reply to Matthew Garrett • • •Joe
in reply to Matthew Garrett • • •If I understand the situation correctly, from your post in which you wrote:
"The distribution-provided Shim first-stage bootloader read this variable, read the SBAT section from the installed copy of grub, realised these conflicted, and refused to boot grub with the "Something has gone seriously wrong" message. "
We encounter a situation where everything is signed, but Shim finds that we have an older copy of Grub. What if, instead of "something has gone seriously wrong", an attempt is made to provide information to the user so they can rescue themselves. If the issue is that they are running an older (typically LTS) Linux system, it's likely that they are fine. A way could be provided to let them boot once, or disable the check.
And maybe for an organization that has a large number of machines that they want to keep highly secure there could be a way to turn the ability to disable the check off, but this wouldn't be the default.
Matthew Garrett
in reply to Joe • • •Adrian Vovk
in reply to Matthew Garrett • • •Ultimately there's a nice solution that is the best of both IMO: the TPM. The user can boot whatever OS they want whenever they want, BUT that OS cannot access any of their data unless the user enters a very cumbersome recovery key.
At that point I can't really think of a use for SB. It would be useful to implement an anti-theft mechanism (unauthorized drive wipe = brick untill you prove device wasn't stolen) but UEFI is missing features for that.
I can't think of another use case...
Paul_IPv6
in reply to Matthew Garrett • • •i mostly agree with where you're going on this but i do think there's a bit of the "not your normal user" going on. folks who tend to want to run non-safe stuff also are probably more informed users and are capable of going through a few hoops (assuming they are well documented) to bypass safe boot.
if you don't know why you need to do this and what the risks are, you probably hadn't ought to touch it.
Mimir
in reply to Matthew Garrett • • •I'm not super familiar with the recent SBAT thing; was it not sufficient to disable secure boot in the BIOS (at least for machines with a physically present user)? That seems like a pretty clear "let me boot what I want, consequences be damned" toggle
i.e. the choice is between "let me boot insecure grub"- which is mostly equivalent to disabling secure boot aiui- and "only let me boot secure things"- what's the case for "secure boot on but let me load old vulnerable grub"
Matthew Garrett
in reply to Mimir • • •lj·rk
in reply to Matthew Garrett • • •> it's difficult to provide enough context for people to know for sure what the tradeoffs are, and the outcomes could well be bad.
Very well said and demonstrates how many freedom absolutist solutions fall flat. While this is about non-technical dogmas, the field where all this plays out is highly technical and to grasp the swath of consequences without at least some knowledge of this is hard.
Will Dormann
in reply to Matthew Garrett • • •gary
in reply to Matthew Garrett • • •Fi, infosec-aspected 🏳️⚧️
in reply to Matthew Garrett • • •gary
in reply to Matthew Garrett • • •mhoye
in reply to Matthew Garrett • • •I have a vague sense that we should be "signing" transactions, both as a proxy for intent as a containment mechanism, not just code. Manifest-like, but as in software declares its origin and comms channels up front in some inspectable, granular way and changes to origin or channel can be interpreted as changes to transactional intent and subject to review.
Bringing community moderation ideas into inspection builds on that; enough people click the 'sus' button on an update, well...
Matthew Garrett
Unknown parent • • •Matthew Garrett
Unknown parent • • •Matthew Garrett
Unknown parent • • •Mason Loring Bliss
in reply to Matthew Garrett • • •Matthew Garrett
in reply to Mason Loring Bliss • • •Matthew Garrett
Unknown parent • • •Matthew Garrett
Unknown parent • • •maswan
in reply to Matthew Garrett • • •And this is a trust relationship between the vendor[s] and the user. A vendor that [is perceived to] break the freedom or security of the user for their own benefit feels like a betrayal, and they will have a hard time rebuilding that trust.
This I think is one of the problems with Microsoft running secure boot, not because I can point at faults in that particular process, but that they have betrayed this trust elsewhere, repeatedly.