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