Salta al contenuto principale


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.

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.

in reply to Matthew Garrett

From the "individual OS" perspective, this is simple enough - if a trusted boot component could be used by a malicious individual to circumvent a security policy such that their computer no longer obeyed the user but instead obeyed said malicious individual, that would be bad!
in reply to Matthew Garrett

But if that trusted boot component is also being used by the user to run software that they *do* want to run, what's the right thing to do? There's a tension here - that software could be used to subvert the user's intent, but it's also the user's intent to use that software. Do you prioritise safety, or freedom? Different people will come to different conclusions here, but I think the right thing to do is *probably* to err on the side of freedom if there's evidence that's what the user wants
in reply to Matthew Garrett

And this is what Microsoft attempted to do in this case! There's no guaranteed way to determine whether a system has Linux installed, but they implemented some heuristics to attempt to identify them and, if detected, not install the update. This clearly didn't always work, and also does have another problem - even if the user didn't have a Linux system installed when the update was applied, they may have wanted to install one later, or boot from a USB stick, or whatever
in reply to Matthew Garrett

So from a freedom maximalist perspective, the right thing would potentially be to never revoke insecure boot components. But in that case, users who *do* want safety and who *don't* want the freedom to install arbitrary outdated Linux systems would also have their desires ignored (and this isn't just proprietary vs free - I might be using a non-grub free software bootloader and still not want insecure versions of grub to boot)
in reply to Matthew Garrett

The problem comes from the fact that we're trying to infer user intent from a set of technical details, and those clearly don't map. But nor can we necessarily infer user intent by simply asking them - it's difficult to provide enough context for people to know for sure what the tradeoffs are, and the outcomes could well be bad.
in reply to Matthew Garrett

Maybe there's a way to clearly describe this to the user in such a way they can make a one-time decision and then everything will work out fine? That would be great! But unfortunately I haven't seen such a mechanism yet, or a description of what percentage of the time a naive user would be expected to make the right choice given the specific context they have around their use of a computer
in reply to Matthew Garrett

(An aside: is secure boot being on by default the right choice? Urrgh that is a hard question and I honestly don't have a great answer! My gut feeling is that the number of people who are in situations where it would make a huge difference isn't that large, but also that's influenced by the fact that it's been on by default since 2012 and maybe someone would have exploited that avenue of attack if it hadn't been, and also situations change and how does someone know if they'll need it tomorrow?)
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.

in reply to Matthew Garrett

also worth noting that the liberty in question is not essential and the safety in question is not temporary
in reply to Matthew Garrett

Or worse, find out you should have been running it since day before yesterday 😲
in reply to Matthew Garrett

I’m not good at predicting the future but I don’t think we will ever pass this watershed. I think the operating systems of the future will use secure boot to get to a known-good state, and everything that runs on the known good state will be sandboxed javascript for regular people and VMs and containers for nerds like us. Operating systems you tinker with will live inside those containers. No one will tinker with or even see the operating system that boots their hardware.
in reply to Rob Isaac

@rmi They kind of need people who can actually write that operating system in the first place, so there's some incentive to not lock it out entirely..
in reply to Matthew Garrett

also the quote was about the liberty of government to tax private entities Vs accepting the proposal of said private entity that it will pay a lump sump for the security needs of the province but still veto the tax.
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.

in reply to Matthew Garrett

my feeling is both secure boot and uefi bios have significant problems, are basically inherently insecure and function as a backdoor/surveillance mechanism; watch for more vulns and issues crop up #mbr virii #'ip'
#mbr
in reply to Matthew Garrett

it is just waaayyy too tempting of a target - the alternative is to get ms to hand over signing keys #crickets
in reply to Matthew Garrett

if you can't look at the codewith binwalk or emba and they are very reticent to share this that is a red herring - lots of people want to know #pkfail
in reply to gary

@gary_alderson I have no idea what you're saying here? All the UEafI secure boot code is pretty easy to examine
@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

in reply to gary

@gary_alderson That is not related to either my question or your earlier statements
@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

in reply to gary

@gary_alderson Could you please explain your point in English without cutting and pasting irrelevant things
@gary
in reply to Matthew Garrett

uefi/secure boot and bios are a big mess - lots (most) of firmware is encrypted - binwalk won't help. air gapping may help for sensitive work but my main point is that this chaos and confusion is carefully calculated - it is not accidental, it affects millions of machines and in the meantime pay attention to the continuing drip - it is not going away #coreboot #air gap #fisa gags #red herrings #surveillance #cve #killchains
in reply to Matthew Garrett

@gary_alderson (How would it be? The CPU needs to execute the code, it's in RAM, you're going to be able to obtain the key)
@gary
in reply to Matthew Garrett

let's just say you're wrong and leave it at that
Questa voce è stata modificata (4 mesi fa)
in reply to gary

@gary_alderson No, let's not say that, because I'm not. Point at the encrypted firmware.
@gary
in reply to Matthew Garrett

@gary_alderson The CPU microcode is encrypted, but that's going to be the case no matter what system firmware you're using. So point at the encrypted firmware.
@gary
in reply to Matthew Garrett

yeah look at pkfail - keys get distributed or are defaults but the point is that it could be solved and tons and tons of brands out there are vulnerable and there is no quick fix - open sourcing bios/secure boot and uefi may be a way to go to remediate and mitigate these gaping low level holes in security
in reply to gary

@gary_alderson They actually don't, latest UEFI implementations at least implement NX, but that's still not encryption. Point at the encrypted firmware.
@gary
in reply to Matthew Garrett

semantics - major and massive problems exist and at such a low level that they are basically invisible - you can change os, format all your drives and you still have problems
in reply to gary

@gary_alderson You made an explicit claim that the firmware was encrypted and couldn't be examined and then said I was wrong when I said otherwise, this is not a semantic argument
@gary
in reply to Matthew Garrett

i made my point - memory protection and signing keys - you can see the files with binwalk but unless you have the key like with pkfail it does you no good - you were and still are wrong on multiple levels
in reply to gary

@gary_alderson (1) pkfail was about the secure boot signing key - this doesn't sign the firmware, it only signs bootloaders
(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

massive problems exist in secure boot, uefi, tpm and legacy - maybe you should sort it out and get a raise
in reply to Matthew Garrett

ms has the keys but won't let people examine the code - why not? ip and national security - they want and need to access - more freedom for corp, more info for the govt but it begs the question why they don't lean fwd on these issues and e2e since if they can access so can other nation states, hackers, and hacktivists - they are collectively looking out for themselves and not putting the best interests of the public and country at the fore
in reply to gary

@gary_alderson The code can be examined. I have examined the code. Anyone can examine the code.
@gary
in reply to Matthew Garrett

If implemented correctly, secure boot protects you from booting firmware that's not signed, but we can't prove it's implemented correctly
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

What the fuck is an SBAT and why does everyone suddenly care
in reply to Matthew Garrett

ms lack of transparency
techtarget.com/searchsecurity/…
in reply to gary

@gary_alderson And how did they identify those issues if it was encrypted?
@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."

in reply to gary

maybe you're the exception since you can read all the code, hashes and binaries in memory #assembly
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.

Questa voce è stata modificata (4 mesi fa)
in reply to Joe

@not2b Better error messages there would probably help a great deal, yes. And maybe allowing a physically present user to override it is an acceptable outcome.
@Joe
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...

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.

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"

Questa voce è stata modificata (4 mesi fa)
in reply to Mimir

@mimir It was, although doing that put Windows in Bitlocker recovery mode if you still want to boot Windows
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.

in reply to Matthew Garrett

I'm curious as to what their heuristic is. I've not been able to figure out any way to have Linux and Windows on the same system in a way that the August Windows update does not install an SBAT update.
in reply to Matthew Garrett

you have malicious insiders but outsiders who breach sensitive subjects get bought off or sued or worse
in reply to Matthew Garrett

Has to be some way for the user to indicate their intent, implicitly or expicitly.
in reply to Matthew Garrett

a computer doesn't care - this is all on you but things like uefi do have an influence - you have no choice there unless you run coreboot, 'freedom' is getting taken for a ride but it may be a national security issue
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...

Unknown parent

Matthew Garrett
@JessTheUnstill Is that much different to having a firmware toggle?
Unknown parent

Matthew Garrett
@Orc You can disable it in the system firmware!
Unknown parent

Matthew Garrett
@Orc Depends if you set a firmware password or not
in reply to Matthew Garrett

@Matthew Garrett This makes me think of Linux and it's ever-growing list of GPL-only symbols, whose only purpose is making life difficult for ZFS developers and users. Free software people shouldn't try to suppress free software they dislike.
Unknown parent

Matthew Garrett
@Orc Yes, but if you have physical access you can downgrade the firmware to something that has a vulnerability, obliterate any dbx updates, all that stuff. It's an improvement over the previous status-quo, not perfect.
Unknown parent

Matthew Garrett
@mkj @JessTheUnstill what's reading the switch?
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.

Questo sito utilizza cookie per riconosce gli utenti loggati e quelli che tornano a visitare. Proseguendo la navigazione su questo sito, accetti l'utilizzo di questi cookie.