sbsign generates invalid grub signatures

Bug #1551629 reported by James Johnston on 2016-03-01
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sbsigntool (Ubuntu)
Undecided
Unassigned

Bug Description

The sbsign utility generates invalid signatures, when verified on MS Windows 7. I believe the issue is that sbsign doesn't hash the image properly. Steps to reproduce:

=== GET A SUITABLE grubx64.efi FOR SIGNING ===

1. Install Ubuntu 15.10. Then install latest sbsigntool package with dpkg -i: sbsigntool_0.6-0ubuntu10_amd64.deb

2. Run grub-install: (note my grub packages are version 2.02~beta2-29ubuntu0.3)

sudo grub-install --no-uefi-secure-boot

=== GENERATE SIGNING KEY ===

3. Generate db key for signing, like this. Note the extra configuration options which I found necessary to get a valid signature on Windows for HelloWorld.efi (e.g. basicConstraints).

SSLCFG="$(mktemp)"
cat > "$SSLCFG" << EOF
[req]
distinguished_name = reqdn
x509_extensions = reqx509

[reqdn]

[reqx509]
subjectKeyIdentifier = hash
# CA must be false because we are directly signing objects with this key:
basicConstraints = critical,CA:false
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
EOF

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Cert db/" \
-days 3650 -nodes -sha256 -config "$SSLCFG" \
-keyout db.key -out db.crt

=== SIGN GRUB ===

4. Sign the installed grub:

sudo sbsign --key db.key --cert db.crt --output grub-signed.efi /boot/efi/EFI/ubuntu/grubx64.efi

=== TEST THE SIGNATURE ON WINDOWS ===

5. Transfer the signed grub-signed.efi file to a Windows 7 SP1 computer. (other versions are probably fine but 7 is what I tested on.)

6. In Windows Explorer, right-click file and click Properties. Go to Digital Signatures tab. Open the signature. Notice that if we view the details it says "This digital signature is not valid" and if we view the certificate, it furthermore says "The digital signature of the object did not verify" - i.e. indicating that somebody has tampered with the EFI since it was signed (yet obviously not the case), as opposed to a cert that is untrusted for some reason.

7. We can vainly try to correct the issue by installing the cert into the root CA database: click "Install Certificate", choose "Place all certificates in the following store", and pick "Trusted Root Certification Authorities." After installing the cert, you need to completely close the file properties, and then open them again. Normally, the certificate should now be "ok". However, Windows still says the signature is bad with the same error as previous.

8. Note that if we repeat the above procedure but sign the very simple HelloWorld.efi from efitools package, the signature will check out OK on Windows once we install the cert as a trusted root in step 7. That's why I think it's a sbsigntool bug and not some mistake in my procedure.

I would assume this is a potential reason why many guides online like http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot?page=0,1 say to use other tools like osslsigncode instead of sbsign if your system rejects the signed binary. Such a workaround indicates a malfunction in sbsign.

Interestingly enough, the official Ubuntu 15.10 binaries from e.g. grub-efi-amd64-signed package have the same problem. Whereas, the Microsoft-signed binaries from shim-signed have no problems. Note I haven't tested the signed binary on an actual UEFI system yet; the fact that Canonical-signed binaries boot on many systems w/out issue suggests that many UEFIs are not as strict as Windows when verifying the signature - however, something is clearly wrong with it and in the future there could be UEFIs that reject these signatures.

As confirmation that the problem is with the signature, the above error message exactly matches with this definition from WinError.h - BAD_DIGEST is a clear indication of the problem...

// MessageId: TRUST_E_BAD_DIGEST
//
// MessageText:
//
// The digital signature of the object did not verify.
//
#define TRUST_E_BAD_DIGEST _HRESULT_TYPEDEF_(0x80096010L)

James Johnston (mail-codenest) wrote :

I am attaching my grubx64.efi and signing certificate/key. This will let you skip steps 1 thru 3 in the test procedure if you want.

James Johnston (mail-codenest) wrote :
  • db.crt Edit (1.1 KiB, application/x-x509-ca-cert)
James Johnston (mail-codenest) wrote :
Safayet Ahmed (safayet-ahmed) wrote :

I believe I have run into similar problems in the past.

Note, in many cases, the UEFI firmware will not verify the GRUB binary itself, but will verify the SHIM against certificates in the UEFI databases. On a standard system, Ubuntu doesn't have their own cert in the UEFI key databases. The SHIM will verify the UBUNTU-signed GRUB image against certificates embedded in the SHIM itself.

Anyway, after seeing your post and doing some more searching I came across this:
https://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/log/

It appears that James Bottomley has some really recent code for sbsign up on kernel.org. I'm about to give it a shot myself and hope it fixes the problem.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sbsigntool (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers