Univention Bugzilla – Bug 45471
Build new SHIM and GRUB with 2017 certificate
Last modified: 2021-09-08 08:09:02 CEST
Out EV certificate used to sign SHIM, GRUB, and the Linux Kernel expired "Sep 20 12:00:00 2017 GMT". We already have a new one, but we need to re-build the complete chain. Care must be taken to include both certificates, as otherwise the new SHIM would not boot old kernels. We should check for a new version of SHIM, best from Ubunto (or some other distribution) to reduce the time Microsoft needs for code review.
I think it is a 'Development internal' issue since it doesn't occur in the customer environment.
shim.c: verify_buffer() { Cryptlib/Pk/CryptAuthenticode.c: AuthenticodeVerify() { Cryptlib/Pk/CryptPkcs7.c: Pkcs7Verify() { 712: X509_STORE_new() allocates a new store 716: X509_STORE_add_cert() in which only the first certificate is loaded, so we can't add multiple. Creating a PEM-bundle and converting that to DER using `openssl x509 -outform der` does not work as only the first certificate is converted. git:rhboot/master still has the same code.
IMHO we shot ourselves in the foot by using the same certificate for both signing our version of 'shim' on the one hand, and 'grub' and our 'linux' kernels on the other hand: If you look at <https://packages.debian.org/source/sid/shim> you will see, that both Ubuntu and Debian are embedding a custom CA into shim, which is valid for 30 years (SuSE: 22 years). That shim is then sent to Microsoft for signing (that process requires to sent a signed .cab file, for which the EV CA is required only AFAIK). This reduces the review process to every 30 years or when 'shim' needs an update. 'grub' and 'linux'-images on the other hand are than signed by that custom CA only. Microsoft only requires the CA certificate to be HW secured, but does not require it to be EV (its only a recommendation). Both Canonical and Debian use a self-signed CA certificate. Quoting <https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/>: | b. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently. I haven't figured out what that is supposed to mean, but the CA must (probably) provide regular CRL updates. There also is <https://launchpad.net/ubuntu/+source/secureboot-db> to update DB and DBX, which looks lite it exists to satisfy that clause. Our version of shim also does not include the MoKManager.efi.signed (it was built, but not installed), which could have been used to load additional certificates into SHIM to trust. I was able to use the one from OpenSUSE and loaded our two certificates from 2014 and 2017 and then was able to boot both UCS 104 and 105 kernels. This tool only works interactively (to satisfy the requirement of UEFI), so it would not have helped with a fully-automatic upgrade of servers, but at least would have allowed the admin to load old kernels on demand *when* at the console. We should include it into our next 'shim' anyway, as this gives admins the opportunity to boot different Linux distributions in UEFI-SB environments. (see some more notes at the end) Also our version of shim is too old and will not get re-accepted by Microsoft: $ grep SSL_VERSION_NUMBER ./Cryptlib/Include/openssl/opensslv.h #define OPENSSL_VERSION_NUMBER 0x0090817fL Quoting <https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/>: | 9. If there are known security vulnerabilities in your submission code, the submission won’t be signed, even if your functionality doesn’t expose that code. For example, the latest known secure versions of OpenSSL are 0.9.8za and 1.0.1h, so if your submission contains earlier versions that contain known vulnerabilities, it won’t be signed. ===== ucr set repository/online/unmaintaed=yes univention-install mokutil modprobe efivarfs mount -t efivarfs efivar /sys/firmware/efi/efivars mokutil --list-enrolled # 02:23:ed:ba:9a:f4:1a:c8:32:37:c5:25:6a:9d:d2:df # Not After : Sep 20 12:00:00 2017 GMT
See <https://mjg59.dreamwidth.org/47438.html> for "Shim review process" r17683 | Bug #45471: shim Package: shim Version: 0.9+1474479173.6c180c6-1A~4.2.0.201710201704 Branch: ucs_4.2-0 Scope: errata4.2-2 git archive --format=tar.xz --prefix=shim-13/ -o ../shim_13.orig.tar.xz 13 repo_admin.py -F -p shim -r 4.2 -s errata4.2-2 svn rm -m 'Bug #45471: Drop SHIM patches' svn+ssh://billy.knut.univention.de/var/svn/patches/shim/4.2-0-0-ucs/13-0.1-errata4.2-2 build-package-ng -r 4.2 -s errata4.2-2 -p shim --force-arch Package: shim Version: 13-0.1A~4.2.0.201710261631 Version: 13-0.1A~4.2.0.201710301703 Branch: ucs_4.2-0 Scope: errata4.2-2
We need sbsigntool_0.6-3.2, which includes <https://github.com/inorton/sbsigntool/commit/951ee95a301674c046f55330cd7460e1314deff2> required for our newer Linux kernel. With UCS-4.2 efivarfs does not get mounted automatically: mount -t efivarfs efivarfs /sys/firmware/efi/efivarfs This is done automatically since systemd-196, but disabled in Debian: view src/core/mount-setup.c +114 #if ENABLE_EFI systemd --version | grep EFI Package: shim Version: 13-0.1A~4.2.0.201711030836 Branch: ucs_4.2-0 Scope: errata4.2-2 Waiting for <https://sysdev.microsoft.com/de-DE/Hardware/member/SubmissionCenter/UefiSubmissionDetails.aspx?SubmissionID=1970446>
Now waiting for review by shim developers: <http://updates.software-univention.de/download/shim-13/>
We will wait for SB support in Debian-Buster. After that Debian will probably back-port that to Debian-Stretch. We will pickup their packages when they are ready.