[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UEFI Revocation List being distributed by Debian



* Paul Wise:

> On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
>
>> It also has to be optional and disabled by default because a future
>> dbx update may be specifically designed to stop Debian systems from
>> booting.  No Debian user will want to install such an update.
>
> Isn't the point of these updates to fix security issues, not to block
> systems from booting?

If Debian signatures are revoked, then the intent is to stop Debian
from booting, for everyone.  The main reason for doing this will
likely be to protect users from harm that did not intent to run Debian
at all, but there is no way to tell those users from everyone else.

According to the signing policy, Debian signatures can be revoked if a
vulnerable Debian kernel is used to kexec other operating systems in
the wild, bypassing their security protections:

| b. Developers might assume that secure boot security requirements
| have been satisfied when their initial boot is complete. However,
| if a secure boot system permits launch of another operating system
| instance after execution of unauthenticated code, the security
| guarantee of secure boot is compromised. If this vulnerability is
| exploited, the submission might be revoked.

<https://techcommunity.microsoft.com/t5/windows-hardware-certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>

I assume “exploited” here means “actual malware abuses signed code”,
not harmless demonstration code.

In order reduce this risk, Debian would have to blacklist earlier
kernels along with kernel updates that fix root-to-ring-0
vulnerabilities (likewise for GRUB and shim).  The signing policy
actually requires this today.  Quoting the same source:

| b. Submitter must design and implement a strong revocation
| mechanism for everything the shim loads, directly and subsequently.

I do not know *any* Linux distribution that does this.  Most system
administrators would really dislike it if they could only boot one
kernel version and have no way to downgrade if there is a kernel
regression.

(We should probably move this discussion to debian-project.)


Reply to: