launchpad signing shimaa64.efi fails to validate
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lp-signing |
New
|
Undecided
|
Unassigned | ||
sbsigntool (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned |
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://
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~
Verification will pass with old sbsign, but it is wrong.
# Generate new key on bionic
update-
openssl x509 -inform der -outform pem -in /var/lib/
cp 15.3-0ubuntu1~
cp 15.3-0ubuntu1~
# self-sign the binary using the old sbsign
sbsign --key /var/lib/
# Detach the signature and print the message digest
sbattach --detach old-sbsign-
openssl pkcs7 -inform der -in old-sbsign-
# upgrade to new sbsign
# check that verifcation now fails
sbverify --cert 15.3-0ubuntu1~
should now fail.
# self-sign with new sbsign
sbsign --key /var/lib/
# Detach the signature and print the message digest
sbattach --detach new-sbsign-
openssl pkcs7 -inform der -in new-sbsign-
# Also detach the launchpad signature and print digest
sbattach --detach lp-sbsign-
openssl pkcs7 -inform der -in lp-sbsign-
The correct digest is, which should be in the new-sbsign-
object: messageDigest (1.2.840.
set:
OCTET STRING:
The wrong digest is, which is in lp & old sbsign signatures:
object: messageDigest (1.2.840.
set:
OCTET STRING:
* 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)
tar xvf ./signed.tar.gz
sbverify --cert 15.3-0ubuntu1~
Signature verification failed
And yet inside bionic-amd64 chroot I get:
# sbverify --cert 15.3-0ubuntu1~
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-
openssl x509 -inform der -outform pem -in /var/lib/
sbsign --key /var/lib/
sbverify --cert /var/lib/
Signature verification OK
Looks like something is dodgy in sbverify in bionic; i.e. it calculates / signs / verifies wrong hash.
description: | updated |
description: | updated |
description: | updated |
Changed in sbsigntool (Ubuntu): | |
status: | New → Fix Released |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Also good to check that existing bionic x64 binaries still verify correctly. I.e. grub / kernel.