Package: sbsigntool
Version: 0.9.2-2
Severity: normal
X-Debbugs-Cc: stribika@???
Dear Maintainer,
I was trying to verify the secure boot signatures on the GRUB and kernel
images. I exported all of the trusted public keys using mokutil, and
converted them to PEM format.
# mokutil --export --pk
# mokutil --export --kek
# mokutil --export --db
# mokutil --export
# for derfile in ./*.der; do
> openssl x509 -inform der -outform pem -in "$derfile" -out
"${derfile}.pem"
> done
# rename 's/.der.pem$/.pem/' ./*.der.pem
# for pemfile in ./*.pem; do
> echo "$pemfile"
> openssl x509 -inform pem -in "$pemfile" -text | grep 'CN ='
> done
./DB-0001.pem
Issuer: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
Subject: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Windows Production PCA 2011
./DB-0002.pem
Issuer: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Corporation Third Party
Marketplace Root
Subject: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Corporation UEFI CA 2011
./DB-0003.pem
Issuer: C = US, O = HP Inc., CN = HP Inc. DB Key 2016 CA
Subject: CN = HP UEFI Secure Boot DB 2017, OU = CODE-SIGN,
C = US, O = HP Inc.
./KEK-0001.pem
Issuer: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Corporation Third Party
Marketplace Root
Subject: C = US, ST = Washington, L = Redmond, O =
Microsoft Corporation, CN = Microsoft Corporation KEK CA 2011
./KEK-0002.pem
Issuer: C = US, O = HP Inc., CN = HP Inc. KEK 2016 CA
Subject: CN = HP UEFI Secure Boot KEK 2017, OU =
CODE-SIGN, C = US, O = HP Inc.
./MOK-0001.pem
Issuer: CN = strib.tech
Subject: CN = strib.tech
./MOK-0002.pem
Issuer: CN = Debian Secure Boot CA
Subject: CN = Debian Secure Boot CA
./PK-0001.pem
Issuer: C = US, O = HP Inc., CN = HP Inc. PK 2016 CA
Subject: CN = HP UEFI Secure Boot PK 2017, OU = CODE-SIGN,
C = US, O = HP Inc.
Then, I attempted to verify each file in /boot with each key.
# for imgfile in /boot/vmlinuz-* /boot/efi/EFI/devuan/*.efi; do
> for pemfile in ./*.pem; do
> sbverify --cert "$pemfile" "$imgfile" &> /dev/null &&
echo "$imgfile is signed with $pemfile"
> done
> done
/boot/efi/EFI/devuan/shimx64.efi is signed with ./DB-0002.pem
The outcome of this action was that only the shim had a valid signature,
which I found strange because secure boot is enabled, and the system
booted successfully. I expected instead that all of these files would
have valid signatures. Here is the error message for the GRUB image, for
example, all the others are the same.
warning: data remaining[1106288 vs 1261192]: gaps between PE/COFF sections?
140271657757696:error:21075075:PKCS7
routines:PKCS7_verify:certificate verify
error:../crypto/pkcs7/pk7_smime.c:284:Verify error:unsupported
certificate purpose
signature 1
image signature issuers:
- /CN=Debian Secure Boot CA
image signature certificates:
- subject: /CN=Debian Secure Boot Signer 2020
issuer: /CN=Debian Secure Boot CA
PKCS7 verification failed
Signature verification failed
These are all files from the official Devuan repo, the packages are
shim-helpers-amd64-signed, grub-efi-amd64-signed, and
linux-image-5.10.0-3-amd64. SHA256 checksums:
87dedf11511a791d154309839b1945005db27f1571d2f9fa5844a7c72b66890b
/boot/vmlinuz-5.10.0-3-amd64
409681bf79c7678c4a4fc9bcb1e6ebac8c855da221fb85736a9a4e5b6bb9afde
/boot/efi/EFI/devuan/fbx64.efi
99f037a16003b465ce42b6ca1e287efe14aa84d90ed46cf448f69f46d0044788
/boot/efi/EFI/devuan/grubx64.efi
ace876d5f0052e6742ee7903771659434668c82d38aaf0e3d264441d984c7a3b
/boot/efi/EFI/devuan/mmx64.efi
599a102b6445fa88392b8c85a31d80ece950624219d846affbfb7131d4bf550b
/boot/efi/EFI/devuan/shimx64.efi
It seems sbverify is more picky about the additional fields in the
certificate than the shim. I also tried another tool, osslsigncode,
which failed with a similar error but was easier to modify than
sbsigntool.
--- osslsigncode-2.1.orig/osslsigncode.c
+++ osslsigncode-2.1/osslsigncode.c
@@ -2521,12 +2521,6 @@ static int verify_authenticode(SIGNATURE
goto out;
}
- /* check extended key usage flag XKU_CODE_SIGN */
- if (!(X509_get_extended_key_usage(signer) & XKU_CODE_SIGN)) {
- printf("Unsupported Signer's certificate purpose XKU_CODE_SIGN\n");
- goto out;
- }
-
verok = 1; /* OK */
out:
if (!verok)
With this patch, it is able to verify the signatures. I am sure this
check is there for a reason, maybe other firmware cares more about this
field, and so it is relevant.
It would be nice to have an option to disable these checks, or at least
make it clear in the error message that the signature is valid, but
there are issues with the certificate. Or you could sign the images with
a certificate that passes this more extensive validation.
Regards,
Andras Stribik
-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 4 (chimaera/ceres)
Release: testing/unstable
Codename: n/a
Architecture: x86_64
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled
Versions of packages sbsigntool depends on:
ii libc6 2.31-9
ii libssl1.1 1.1.1j-1
ii libuuid1 2.36.1-7+devuan1
sbsigntool recommends no packages.
sbsigntool suggests no packages.
-- no debconf information