Activity log for bug #1921387

Date Who What changed Old value New value Message
2021-03-25 12:59:51 Dimitri John Ledkov bug added bug
2021-03-25 13:00:00 Dimitri John Ledkov bug task added sbsigntool (Ubuntu)
2021-03-25 13:01:27 Dimitri John Ledkov description launchpad signing shimaa64.efi fails to validate 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 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 launchpad signing shimaa64.efi fails to validate 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 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
2021-03-25 13:05:32 Dimitri John Ledkov description launchpad signing shimaa64.efi fails to validate 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 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 launchpad signing shimaa64.efi fails to validate 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.
2021-03-25 14:10:06 Dimitri John Ledkov description launchpad signing shimaa64.efi fails to validate 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. [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. * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c /var/lib/shim-signed/mok/MOK.der [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.
2021-03-25 14:10:13 Dimitri John Ledkov nominated for series Ubuntu Bionic
2021-03-25 14:10:13 Dimitri John Ledkov bug task added sbsigntool (Ubuntu Bionic)
2021-03-25 14:10:22 Dimitri John Ledkov sbsigntool (Ubuntu): status New Fix Released
2021-03-25 14:12:26 Dimitri John Ledkov 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. * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c /var/lib/shim-signed/mok/MOK.der [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. [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.  * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck  * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c /var/lib/shim-signed/mok/MOK.der [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.
2021-03-25 14:13:16 Dimitri John Ledkov 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.  * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck  * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi. signed -c /var/lib/shim-signed/mok/MOK.der [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. [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.  * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck  * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi.signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi.signed -c /var/lib/shim-signed/mok/MOK.der [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.
2021-03-25 14:23:16 Dimitri John Ledkov 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.  * Signatures produced by sbsign in bionic, must be able to verify with pesigcheck  * Existing signatures generated by launchpad should fail validation ie. # 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 ... Signature verification failed Is the correct output # Test that pesigcheck fails too openssl x509 -outform der -out 15.3-0ubuntu1~ppa1/control/uefi.der -in 15.3-0ubuntu1~ppa1/control/uefi.crt pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi.signed -c 15.3-0ubuntu1~ppa1/control/uefi.der pesigcheck: "15.3-0ubuntu1~ppa1/shimaa64.efi.signed" is invalid. # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 pesigcheck -i 15.3-0ubuntu1~ppa1/shimaa64.efi.signed -c /var/lib/shim-signed/mok/MOK.der [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. [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. # 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 ... Signature verification failed Is the correct output # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 Copy the signed binary & cert to focal, and check that sbverify verifies them. [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.
2021-03-25 14:54:03 Dimitri John Ledkov 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. # 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 ... Signature verification failed Is the correct output # Generate new key on bionic, resign using new sbsigntool, and check that it is now all good: 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 Copy the signed binary & cert to focal, and check that sbverify verifies them. [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. [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 .$.\.. [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.
2021-03-25 16:30:06 Łukasz Zemczak 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 .$.\.. [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. [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.
2021-03-25 16:31:00 Łukasz Zemczak sbsigntool (Ubuntu Bionic): status New Fix Committed
2021-03-25 16:31:02 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2021-03-25 16:31:05 Łukasz Zemczak bug added subscriber SRU Verification
2021-03-25 16:31:10 Łukasz Zemczak tags verification-needed verification-needed-bionic
2021-03-25 16:55:02 Dimitri John Ledkov 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. [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.signed 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 new-sbsign.efi.signed 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.
2021-03-25 17:05:14 Dimitri John Ledkov tags verification-needed verification-needed-bionic verification-done verification-done-bionic
2021-03-29 10:02:49 Colin Watson affects launchpad lp-signing
2021-04-06 22:44:19 Launchpad Janitor sbsigntool (Ubuntu Bionic): status Fix Committed Fix Released
2021-04-06 22:44:24 Brian Murray removed subscriber Ubuntu Stable Release Updates Team