https://mjg59.dreamwidth.org/60248.html
Account name: [ ] Password [ ] [Log in]
(OpenID?) (Forgot it?) [ ] Remember Me
You're viewing [personal profile] mjg59's journal
Create a Dreamwidth Account Learn More
[ ] [Interest ] [Go]
Reload page in style: site light
Matthew Garrett
Responsible stewardship of the UEFI secure boot ecosystem
Responsible stewardship of the UEFI secure boot ecosystem
Jul. 11th, 2022 02:45 pm
[personal profile] mjg59
After I mentioned that Lenovo are now shipping laptops that only boot
Windows by default, a few people pointed to a Lenovo document that
says:
`Starting in 2022 for Secured-core PCs it is a Microsoft requirement
for the 3rd Party Certificate to be disabled by default.'
"Secured-core" is a term used to describe machines that meet a
certain set of Microsoft requirements around firmware security, and
by and large it's a good thing - devices that meet these requirements
are resilient against a whole bunch of potential attacks in the early
boot process. But unfortunately the 2022 requirements don't seem to
be publicly available, so it's difficult to know what's being asked
for and why. But first, some background.
Most x86 UEFI systems that support Secure Boot trust at least two
certificate authorities:
1) The Microsoft Windows Production PCA - this is used to sign the
bootloader in production Windows builds. Trusting this is sufficient
to boot Windows.
2) The Microsoft Corporation UEFI CA - this is used by Microsoft to
sign non-Windows UEFI binaries, including built-in drivers for
hardware that needs to work in the UEFI environment (such as GPUs and
network cards) and bootloaders for non-Windows.
The apparent secured-core requirement for 2022 is that the second of
these CAs should not be trusted by default. As a result, drivers or
bootloaders signed with this certificate will not run on these
systems. This means that, out of the box, these systems will not boot
anything other than Windows[1].
Given the association with the secured-core requirements, this is
presumably a security decision of some kind. Unfortunately, we have
no real idea what this security decision is intended to protect
against. The most likely scenario is concerns about the (in)security
of binaries signed with the third-party signing key - there are some
legitimate concerns here, but I'm going to cover why I don't think
they're terribly realistic.
The first point is that, from a boot security perspective, a signed
bootloader that will happily boot unsigned code kind of defeats the
point. Kaspersky did it anyway. The second is that even a signed
bootloader that is intended to only boot signed code may run into
issues in the event of security vulnerabilities - the Boothole
vulnerabilities are an example of this, covering multiple issues in
GRUB that could allow for arbitrary code execution and potential
loading of untrusted code.
So we know that signed bootloaders that will (either through accident
or design) execute unsigned code exist. The signatures for all the
known vulnerable bootloaders have been revoked, but that doesn't mean
there won't be other vulnerabilities discovered in future.
Configuring systems so that they don't trust the third-party CA means
that those signed bootloaders won't be trusted, which means any
future vulnerabilities will be irrelevant. This seems like a simple
choice?
There's actually a couple of reasons why I don't think it's anywhere
near that simple. The first is that whenever a signed object is
booted by the firmware, the trusted certificate used to verify that
object is measured into PCR 7 in the TPM. If a system previously
booted with something signed with the Windows Production CA, and is
now suddenly booting with something signed with the third-party UEFI
CA, the values in PCR 7 will be different. TPMs support "sealing" a
secret - encrypting it with a policy that the TPM will only decrypt
it if certain conditions are met. Microsoft make use of this for
their default Bitlocker disk encryption mechanism. The disk
encryption key is encrypted by the TPM, and associated with a
specific PCR 7 value. If the value of PCR 7 doesn't match, the TPM
will refuse to decrypt the key, and the machine won't boot. This
means that attempting to attack a Windows system that has Bitlocker
enabled using a non-Windows bootloader will fail - the system will be
unable to obtain the disk unlock key, which is a strong indication to
the owner that they're being attacked.
The second is that this is predicated on the idea that removing the
third-party bootloaders and drivers removes all the vulnerabilities.
In fact, there's been rather a lot of vulnerabilities in the Windows
bootloader. A broad enough vulnerability in the Windows bootloader is
arguably a lot worse than a vulnerability in a third-party loader,
since it won't change the PCR 7 measurements and the system will boot
happily. Removing trust in the third-party CA does nothing to protect
against this.
The third reason doesn't apply to all systems, but it does to many.
System vendors frequently want to ship diagnostic or management
utilities that run in the boot environment, but would prefer not to
have to go to the trouble of getting them all signed by Microsoft.
The simple solution to this is to ship their own certificate and sign
all their tooling directly - the secured-core Lenovo I'm looking at
currently is an example of this, with a Lenovo signing certificate.
While everything signed with the third-party signing certificate goes
through some degree of security review, there's no requirement for
any vendor tooling to be reviewed at all. Removing the third-party CA
does nothing to protect the user against the code that's most likely
to contain vulnerabilities.
Obviously I may be missing something here - Microsoft may well have a
strong technical justification. But they haven't shared it, and so
right now we're left making guesses. And right now, I just don't see
a good security argument.
But let's move on from the technical side of things and discuss the
broader issue. The reason UEFI Secure Boot is present on most x86
systems is that Microsoft mandated it back in 2012. Microsoft chose
to be the only trusted signing authority. Microsoft made the decision
to assert that third-party code could be signed and trusted.
We've certainly learned some things since then, and a bunch of things
have changed. Third-party bootloaders based on the Shim
infrastructure are now reviewed via a community-managed process.
We've had a productive coordinated response to the Boothole incident,
which also taught us that the existing revocation strategy wasn't
going to scale. In response, the community worked with Microsoft to
develop a specification for making it easier to handle similar events
in future. And it's also worth noting that after the initial Boothole
disclosure was made to the GRUB maintainers, they proactively sought
out other vulnerabilities in their codebase rather than simply
patching what had been reported. The free software community has gone
to great lengths to ensure third-party bootloaders are compatible
with the security goals of UEFI Secure Boot.
So, to have Microsoft, the self-appointed steward of the UEFI Secure
Boot ecosystem, turn round and say that a bunch of binaries that have
been reviewed through processes developed in negotiation with
Microsoft, implementing technologies designed to make management of
revocation easier for Microsoft, and incorporating fixes for
vulnerabilities discovered by the developers of those binaries who
notified Microsoft of these issues despite having no obligation to do
so, and which have then been signed by Microsoft are now considered
by Microsoft to be insecure is, uh, kind of impolite? Especially when
unreviewed vendor-signed binaries are still considered trustworthy,
despite no external review being carried out at all.
If Microsoft had a set of criteria used to determine whether
something is considered sufficiently trustworthy, we could determine
which of these we fell short on and do something about that. From a
technical perspective, Microsoft could set criteria that would allow
a subset of third-party binaries that met additional review be
trusted without having to trust all third-party binaries[2]. But,
instead, this has been a decision made by the steward of this
ecosystem without consulting major stakeholders.
If there are legitimate security concerns, let's talk about them and
come up with solutions that fix them without doing a significant
amount of collateral damage. Don't complain about a vendor blocking
your apps and then do the same thing yourself.
[Edit to add: there seems to be some misunderstanding about where
this restriction is being imposed. I bought this laptop because I'm
interested in investigating the Microsoft Pluton security processor,
but Pluton is not involved at all here. The restriction is being
imposed by the firmware running on the main CPU, not any sort of
functionality implemented on Pluton]
[1] They'll also refuse to run any drivers that are stored in flash
on Thunderbolt devices, which means eGPU setups may be more
complicated, as will netbooting off Thunderbolt-attached NICs
[2] Use a different leaf cert to sign the new trust tier, add the old
leaf cert to dbx unless a config option is set, leave the existing
intermediate in db
Tags:
* advogato,
* fedora
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
---------------------------------------------------------------------
* 14 comments
* Reply
---------------------------------------------------------------------
Flat | Top-Level Comments Only
no subject
Date: 2022-07-12 06:10 am (UTC)
From: (Anonymous)
Is there an especially good reason that the Windows bootloader
couldn't be signed by the Microsoft Corporation UEFI CA? Dogfooding
that would guarantee this couldn't happen in the future.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
no subject
Date: 2022-07-12 06:16 am (UTC)
From: [personal profile] mjg59
Not aware of any technical reason, but I assume that these are CAs
managed by different teams and integrating the Windows build process
into the third-party signing chain would probably be a lot of work.
Also, Windows would then stop booting on these machines that have
already been deployed.
* Link
* Reply
* Thread from start
* Parent
Yes, I used to be a lawyer
Date: 2022-07-12 08:57 am (UTC)
From: [identity profile] matej.ceplovi.cz
Did this look as a polite request by Microsoft to be sued for
anti-competitive practices to anybody else, or is it just me? I am
certain, people in Brussels will be happy to fine them again.
* Link
* Reply
* Thread
* Hide 2 comments
* Show 2 comments
Re: Yes, I used to be a lawyer
Date: 2022-07-12 10:08 am (UTC)
From: (Anonymous)
Will take probably five to ten years. But yes, we should.
The FSF, Red Hat, Canonical and other should've done that back in
2012 instead of trying to fix a hurdle with code.
* Link
* Reply
* Thread from start
* Parent
Re: Yes, I used to be a lawyer
Date: 2022-07-12 11:13 am (UTC)
From: (Anonymous)
I'd like to see them to fine Apple and Google too. They do much worse
for Macs and Chromebooks. (To be fair, their security is good and
Chromebooks even allow to flash firmware, but they do not pay
attention to 3rd party OS at all.)
* Link
* Reply
* Thread from start
* Parent
update the threath model
Date: 2022-07-12 10:08 am (UTC)
From: (Anonymous)
IMHO there is a lot of focus on secure boot, when a lot of devices
nowadays reboots only on software or firmware updates, and for the
remaing times go.on sleep.
* Link
* Reply
Take a look at your own support of centralized corporate control
first.
Date: 2022-07-12 01:27 pm (UTC)
From: (Anonymous)
>Don't complain about a vendor blocking your apps and then do the
same thing yourself.
Says the guy putting his website behind cloudflare that blocks every
browser except the megacorp ones.
* Link
* Reply
* Thread
* Hide 1 comment
* Show 1 comment
Re: Take a look at your own support of centralized corporate control
first.
Date: 2022-07-12 03:46 pm (UTC)
From: (Anonymous)
Uh, Matthew doesn't own Dreamwidth.
* Link
* Reply
* Thread from start
* Parent
no subject
Date: 2022-07-12 07:55 pm (UTC)
From: (Anonymous)
Whether this is a reasonable security measure or nonsense is way
above my pay grade... but this and your earlier blog post is being
read by many - and repeated by highly-read "authorities" as meaning
signed distros can't be booted in secure mode.
That simply ain't so. True they won't secure boot by "default", but
the non-default is not turning off secure mode. It's enabling 3rd
party UEFI CA in bios. And it's not just the Z series. All the newer
ThinkPads default to no 3rd parts certs - and all have the option to
enable them w/out turning off secure boot.
You'd be doing your readers - and those who follow those misreading
your blog - a great service by making this clear.
regards,
Z.
* Link
* Reply
* Thread
* Hide 4 comments
* Show 4 comments
no subject
Date: 2022-07-12 08:36 pm (UTC)
From: (Anonymous)
This is only step 1 for Microsoft
step 2 is removing the 3rd party UEFI CA altogether once they don't
get sufficient pushback from step 1 to revert it
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 3 comments
* Show 3 comments
no subject
Date: 2022-07-12 08:50 pm (UTC)
From: [personal profile] mjg59
They can't remove it entirely, since it's required for any cases
where you need additional UEFI drivers for hardware to work (eg, any
desktop plug-in GPUs)
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 2 comments
* Show 2 comments
no subject
Date: 2022-07-12 09:43 pm (UTC)
From: (Anonymous)
These are business machines. No company with centrally managed
machines is going to allow the purchase of a laptop that allows a
user to boot into a Linux live USB and work on the windows registry
as data. End users' machines must be able to block 3rd party certs.
It seems to me like having a simple BIOS option allows non managed
hardware to boot anything the user wishes, while stopping non-Windows
boots via a BIOS control with a BIOS password.
* Link
* Reply
* Thread from start
* Parent
* Thread
* Hide 1 comment
* Show 1 comment
no subject
Date: 2022-07-12 10:12 pm (UTC)
From: [personal profile] mjg59
Enterprises are in a position to modify firmware configuration during
initial provisioning to set whatever secure boot policy they want.
There's no need for the machines to ship with restrictive defaults.
`No company with centrally managed machines is going to allow the
purchase of a laptop that allows a user to boot into a Linux live USB
and work on the windows registry as data.'
That's odd, because every Thinkpad sold from 2012 until now has
trusted the third party certificate by default and I'm pretty sure
Lenovo have been selling them to businesses with centrally managed
machines during that time.
* Link
* Reply
* Thread from start
* Parent
More info
Date: 2022-07-12 07:57 pm (UTC)
From: (Anonymous)
Secure-core PCs is a term for bussiness computers. Look for
"Secured-core PCs site:microsoft.com" in google.
You will find info like this:
`Windows secured-core PCs are designed to provide an "On-By-Default"
security experience for businesses and users. What this means is that
from the moment a user takes the device out of the box and turns it
on, businesses can be confident that the machine has protections in
place that mitigate
security risks and simplify the end user experience in configuring
the device.
/q>
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWOXAT
Other secure-core PCs are listed in: https://www.microsoft.com/en-us/
windows/business/devices?col=secured-core-pcs
'
* Link
* Reply
* Previous Entry
* Add Memory
* Share This Entry
* Next Entry
* 14 comments
* Reply
Flat | Top-Level Comments Only
Profile
Matthew Garrett
About Matthew
Power management, mobile and firmware developer on Linux. Security
developer at Aurora. Ex-biologist. [personal profile] mjg59 on
Twitter. Content here should not be interpreted as the opinion of my
employer.
Page Summary
* (Anonymous) - (no subject)
* [identity profile] matej.ceplovi.cz - Yes, I used to be a lawyer
* (Anonymous) - update the threath model
* (Anonymous) - Take a look at your own support of centralized
corporate control first.
* (Anonymous) - (no subject)
* (Anonymous) - More info
Expand Cut Tags
No cut tags
Top of page