[Bug 1921387] Re: launchpad signing shimaa64.efi fails to validate
Łukasz Zemczak
1921387 at bugs.launchpad.net
Thu Mar 25 16:31:11 UTC 2021
Hello Dimitri, or anyone else affected,
Accepted sbsigntool into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/sbsigntool/0.9.2-2ubuntu1~18.04.1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Description changed:
[Impact]
* Calculating the hash of the binary is ill defined if there are gaps
in sections, or sections are not aligned to ensure that signature table
is aligned.
* This results in sbsign/sbverify to calculate incorrect hash when
there are gaps, such as in shimaa64.efi as built on focal with sbat.
* This was fixed in eoan, but launchpad signing service uses sbsign
from bionic.
* Thus if binaries have gaps launchpad is producing signatures that are
covering the wrong authenticode hash.
[Test Plan]
* Signatures produced by sbsign in bionic, must be able to verify with
sbverify from focal or later.
* Old signatures generated by launchpad should fail validation
* Enrolling certificate into db and booting secureboot arm VM must work
ie.
# install old sbsign
# Test old launchpad generated signature, ensure that it fails:
cd $(mktemp -d)
wget http://ppa.launchpad.net/xnox/nonvirt/ubuntu/dists/hirsute/main/signed/shim-arm64/15.3-0ubuntu1~ppa1/signed.tar.gz
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Verification will pass with old sbsign, but it is wrong.
# Generate new key on bionic
update-secureboot-policy --new-key
openssl x509 -inform der -outform pem -in /var/lib/shim-signed/mok/MOK.der -out /var/lib/shim-signed/mok/MOK.pem
cp 15.3-0ubuntu1~ppa1/shimaa64.efi old-sbsign.efi
cp 15.3-0ubuntu1~ppa1/shimaa64.efi new-sbsign.efi
# self-sign the binary using the old sbsign
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-signed/mok/MOK.pem old-sbsign.efi
# Detach the signature and print the message digest
sbattach --detach old-sbsign-signature.p7c old-sbsign.efi
openssl pkcs7 -inform der -in old-sbsign-signature.p7c -print | grep -A5
messageDi
-
# upgrade to new sbsign
# check that verifcation now fails
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
should now fail.
# self-sign with new sbsign
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-signed/mok/MOK.pem new-sbsign.efi
# Detach the signature and print the message digest
sbattach --detach new-sbsign-signature.p7c old-sbsign.efi
openssl pkcs7 -inform der -in new-sbsign-signature.p7c -print | grep -A5
messageDi
# Also detach the launchpad signature and print digest
sbattach --detach lp-sbsign-signature.p7c
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
openssl pkcs7 -inform der -in lp-sbsign-signature.p7c -print | grep -A5
messageDi
-
The correct digest is, which should be in the new-sbsign-signature.p7c:
- object: messageDigest (1.2.840.113549.1.9.4)
- set:
- OCTET STRING:
- 0000 - 6a 83 1f 9e cb 7a 68 7f-17 c0 9d 81 c0 j....zh......
- 000d - 6b 17 b2 c3 1c d7 ed b5-b3 89 49 a3 c1 k.........I..
- 001a - 8d 75 59 d3 b3 11 .uY...
+ object: messageDigest (1.2.840.113549.1.9.4)
+ set:
+ OCTET STRING:
+ 0000 - 6a 83 1f 9e cb 7a 68 7f-17 c0 9d 81 c0 j....zh......
+ 000d - 6b 17 b2 c3 1c d7 ed b5-b3 89 49 a3 c1 k.........I..
+ 001a - 8d 75 59 d3 b3 11 .uY...
The wrong digest is, which is in lp & old sbsign signatures:
- object: messageDigest (1.2.840.113549.1.9.4)
- set:
- OCTET STRING:
- 0000 - 2a c3 bb e6 20 27 6b b2-58 f8 8d 50 eb *... 'k.X..P.
- 000d - 1e 88 68 a3 12 08 7a 1d-27 e5 42 e6 0e ..h...z.'.B..
- 001a - e4 24 9a 5c 0a 92 .$.\..
+ object: messageDigest (1.2.840.113549.1.9.4)
+ set:
+ OCTET STRING:
+ 0000 - 2a c3 bb e6 20 27 6b b2-58 f8 8d 50 eb *... 'k.X..P.
+ 000d - 1e 88 68 a3 12 08 7a 1d-27 e5 42 e6 0e ..h...z.'.B..
+ 001a - e4 24 9a 5c 0a 92 .$.\..
+ * Additionally to that, check that existing bionic x64 binaries still
+ verify correctly. I.e. grub / kernel.
[Where problems could occur]
* Existing edk2 OVMF machines in bionic possibly are calculating
checksums unpadded, and thus this change will make the new signatures
fail to validate in edk2 OVMF. However, the binaries on amd64 do not
have gaps and thus have always had correct signatures. arm64 binaries
with gaps do not exist in bionic.
[Other Info]
Original bug report:
launchpad signed shimaa64.efi fails to validate on focal
cd $(mktemp -d)
wget
http://ppa.launchpad.net/xnox/nonvirt/ubuntu/dists/hirsute/main/signed
/shim-arm64/15.3-0ubuntu1~ppa1/signed.tar.gz
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Signature verification failed
And yet inside bionic-amd64 chroot I get:
# sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt 15.3-0ubuntu1~ppa1/shimaa64.efi.signed
warning: gap in section table:
.data : 0x0007f000 - 0x000b3800,
.sbat : 0x000b4000 - 0x000b5000,
gaps in the section table may result in different checksums
warning: data remaining[740864 vs 800872]: gaps between PE/COFF sections?
Signature verification OK
However,
If in xenial-amd64 I perform
update-secureboot-policy new-key
openssl x509 -inform der -outform pem -in /var/lib/shim-signed/mok/MOK.der -out /var/lib/shim-signed/mok/MOK.pem
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-
signed/mok/MOK.pem 15.3-0ubuntu1~ppa1/shimaa64.efi
sbverify --cert /var/lib/shim-signed/mok/MOK.pem 15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Signature verification OK
Looks like something is dodgy in sbverify in bionic; i.e. it calculates
/ signs / verifies wrong hash.
** Changed in: sbsigntool (Ubuntu Bionic)
Status: New => Fix Committed
** Tags added: verification-needed verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to sbsigntool in Ubuntu.
https://bugs.launchpad.net/bugs/1921387
Title:
launchpad signing shimaa64.efi fails to validate
Status in Launchpad itself:
New
Status in sbsigntool package in Ubuntu:
Fix Released
Status in sbsigntool source package in Bionic:
Fix Committed
Bug description:
[Impact]
* Calculating the hash of the binary is ill defined if there are gaps
in sections, or sections are not aligned to ensure that signature
table is aligned.
* This results in sbsign/sbverify to calculate incorrect hash when
there are gaps, such as in shimaa64.efi as built on focal with sbat.
* This was fixed in eoan, but launchpad signing service uses sbsign
from bionic.
* Thus if binaries have gaps launchpad is producing signatures that
are covering the wrong authenticode hash.
[Test Plan]
* Signatures produced by sbsign in bionic, must be able to verify
with sbverify from focal or later.
* Old signatures generated by launchpad should fail validation
* Enrolling certificate into db and booting secureboot arm VM must
work
ie.
# install old sbsign
# Test old launchpad generated signature, ensure that it fails:
cd $(mktemp -d)
wget http://ppa.launchpad.net/xnox/nonvirt/ubuntu/dists/hirsute/main/signed/shim-arm64/15.3-0ubuntu1~ppa1/signed.tar.gz
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Verification will pass with old sbsign, but it is wrong.
# Generate new key on bionic
update-secureboot-policy --new-key
openssl x509 -inform der -outform pem -in /var/lib/shim-signed/mok/MOK.der -out /var/lib/shim-signed/mok/MOK.pem
cp 15.3-0ubuntu1~ppa1/shimaa64.efi old-sbsign.efi
cp 15.3-0ubuntu1~ppa1/shimaa64.efi new-sbsign.efi
# self-sign the binary using the old sbsign
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-signed/mok/MOK.pem old-sbsign.efi
# Detach the signature and print the message digest
sbattach --detach old-sbsign-signature.p7c old-sbsign.efi
openssl pkcs7 -inform der -in old-sbsign-signature.p7c -print | grep
-A5 messageDi
# upgrade to new sbsign
# check that verifcation now fails
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
should now fail.
# self-sign with new sbsign
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-signed/mok/MOK.pem new-sbsign.efi
# Detach the signature and print the message digest
sbattach --detach new-sbsign-signature.p7c old-sbsign.efi
openssl pkcs7 -inform der -in new-sbsign-signature.p7c -print | grep
-A5 messageDi
# Also detach the launchpad signature and print digest
sbattach --detach lp-sbsign-signature.p7c
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
openssl pkcs7 -inform der -in lp-sbsign-signature.p7c -print | grep
-A5 messageDi
The correct digest is, which should be in the new-sbsign-signature.p7c:
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - 6a 83 1f 9e cb 7a 68 7f-17 c0 9d 81 c0 j....zh......
000d - 6b 17 b2 c3 1c d7 ed b5-b3 89 49 a3 c1 k.........I..
001a - 8d 75 59 d3 b3 11 .uY...
The wrong digest is, which is in lp & old sbsign signatures:
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - 2a c3 bb e6 20 27 6b b2-58 f8 8d 50 eb *... 'k.X..P.
000d - 1e 88 68 a3 12 08 7a 1d-27 e5 42 e6 0e ..h...z.'.B..
001a - e4 24 9a 5c 0a 92 .$.\..
* Additionally to that, check that existing bionic x64 binaries still
verify correctly. I.e. grub / kernel.
[Where problems could occur]
* Existing edk2 OVMF machines in bionic possibly are calculating
checksums unpadded, and thus this change will make the new signatures
fail to validate in edk2 OVMF. However, the binaries on amd64 do not
have gaps and thus have always had correct signatures. arm64 binaries
with gaps do not exist in bionic.
[Other Info]
Original bug report:
launchpad signed shimaa64.efi fails to validate on focal
cd $(mktemp -d)
wget
http://ppa.launchpad.net/xnox/nonvirt/ubuntu/dists/hirsute/main/signed
/shim-arm64/15.3-0ubuntu1~ppa1/signed.tar.gz
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt
15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Signature verification failed
And yet inside bionic-amd64 chroot I get:
# sbverify --cert 15.3-0ubuntu1~ppa1/control/uefi.crt 15.3-0ubuntu1~ppa1/shimaa64.efi.signed
warning: gap in section table:
.data : 0x0007f000 - 0x000b3800,
.sbat : 0x000b4000 - 0x000b5000,
gaps in the section table may result in different checksums
warning: data remaining[740864 vs 800872]: gaps between PE/COFF sections?
Signature verification OK
However,
If in xenial-amd64 I perform
update-secureboot-policy new-key
openssl x509 -inform der -outform pem -in /var/lib/shim-signed/mok/MOK.der -out /var/lib/shim-signed/mok/MOK.pem
sbsign --key /var/lib/shim-signed/mok/MOK.priv --cert /var/lib/shim-
signed/mok/MOK.pem 15.3-0ubuntu1~ppa1/shimaa64.efi
sbverify --cert /var/lib/shim-signed/mok/MOK.pem 15.3-0ubuntu1~ppa1/shimaa64.efi.signed
Signature verification OK
Looks like something is dodgy in sbverify in bionic; i.e. it
calculates / signs / verifies wrong hash.
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1921387/+subscriptions
More information about the foundations-bugs
mailing list