Shim 15.5 for ECOS Technology GmbH #228

ecos-platypus · 2022-02-17T06:35:10Z

Edits:

2022-02-21: Patches for forcing secure mode in shim and GRUB were added.
2022-02-24: Formatting of README.md and ISSUE_TEMPLATE.md was updated to match the templates modified in a82f9fe and 28f9f9f

Make sure you have provided the following information:

link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
- https://github.com/ecos-platypus/shim-review/tree/ECOS_Technology_GmbH-shim-x64-20220224
completed README.md file with the necessary information
- https://github.com/ecos-platypus/shim-review/blob/ECOS_Technology_GmbH-shim-x64-20220224/README.md
shim.efi to be signed
- https://github.com/ecos-platypus/shim-review/blob/ECOS_Technology_GmbH-shim-x64-20220224/shimx64.efi
public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
- https://github.com/ecos-platypus/shim-review/blob/ECOS_Technology_GmbH-shim-x64-20220224/ECOS_Tech_Code_signing_Certificate_Globalsign_2022.cer
binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
- vendor_db is not used
any extra patches to shim via your own git tree or as files
- https://github.com/ecos-platypus/shim-review/tree/ECOS_Technology_GmbH-shim-x64-20220224/patches-shim
any extra patches to grub via your own git tree or as files
- https://github.com/ecos-platypus/shim-review/tree/ECOS_Technology_GmbH-shim-x64-20220224/patches-grub
build logs
- https://github.com/ecos-platypus/shim-review/blob/ECOS_Technology_GmbH-shim-x64-20220224/build.log
a Dockerfile to reproduce the build of the provided shim EFI binaries
- https://github.com/ecos-platypus/shim-review/blob/ECOS_Technology_GmbH-shim-x64-20220224/Dockerfile

What organization or people are asking to have this signed?

ECOS Technology GmbH

https://www.ecos.de/en/

What product or service is this for?

ECOS Secure Boot Stick (SBS)

The ECOS Secure Boot Stick is a secure ThinClient on a USB stick.
It is approved by the german BSI for use in governmental organisations.

https://www.ecos.de/en/products/secure-boot-stick

Please create your shim binaries starting with the 15.5 shim release tar file: https://github.com/rhboot/shim/releases/download/15.5/shim-15.5.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.5 and contains the appropriate gnu-efi source.

Please confirm this as the origin your shim.

Yes.

What's the justification that this really does need to be signed for the whole world to be able to boot it?

The SBS is used with a variety of customer devices.
Enrolling custom secure boot keys on each customer devices is infeasible.
Moreover, the SBS is designed to be used with customer devices without additional setup.
We need our own publicly signed shim as we custom-build our kernels for quicker firmware updates and therefore cannot use the shim of a distribution like Fedora.

How do you manage and protect the keys used in your SHIM?

The key is stored on a FIPS-140-2 Token.
The key is part of our EV code signing certificate.

Do you use EV certificates as embedded certificates in the SHIM?

Yes.

If you use new vendor_db functionality, are any hashes allow-listed?

If yes: for what binaries?

The new vendor_db functionality is not used.

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

Yes, it is included in all used kernels.

if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) and if you are shipping the shim_lock module CVE-2021-3418 fixed ?

Yes, all the CVEs are fixed in GRUB 2.06.

"Please specifically confirm that you add a vendor specific SBAT entry for SBAT header in each binary that supports SBAT metadata ( grub2, fwupd, fwupdate, shim + all child shim binaries )" to shim review doc ?

Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim

Where your code is only slightly modified from an upstream vendor's, please also preserve their SBAT entries to simplify revocation.

Yes.

shim:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,1,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.ecos,1,ECOS Technology GmbH,shim,15.5,mail:security@ecos.de

GRUB:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.ecos,1,ECOS Technology GmbH,grub2,2.06-r1,mail:security@ecos.de

Were your old SHIM hashes provided to Microsoft ?

Yes.

Did you change your certificate strategy, so that affected by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) grub2 bootloaders can not be verified ?

We use a new EV certificate embbeded in shim for verification of the loaded GRUB bootloader.
Older versions of GRUB were signed with an old EV certificate and hence cannot be verified by the new shim.

What exact implementation of Secureboot in grub2 ( if this is your bootloader ) you have ?

* Upstream grub2 shim_lock verifier or * Downstream RHEL/Fedora/Debian/Canonical like implementation ?

We use the upstream grub2 shim_lock verifier.

Which modules are built into your signed grub image?

acpi
archelp
bitmap
bitmap_scale
boot
btrfs
bufio
cpuid
crypto
datetime
disk
diskfilter
echo
efi_gop
efi_uga
ext2
extcmd
f2fs
fat
font
fshelp
gcry_crc
gcry_rsa
gcry_sha1
gcry_sha512
gettext
gfxmenu
gfxterm
gfxterm_background
gfxterm_menu
gzio
halt
iorw
keylayouts
keystatus
linux
loadenv
loopback
ls
lzopio
memdisk
minicmd
minix
mmap
mpi
net
normal
part_ecx
part_gpt
part_msdos
password_pbkdf2
pbkdf2
pgp
png
priority_queue
probe
procfs
raid6rec
regexp
relocator
smbios
terminal
test
trig
video
video_colors
video_fb
videoinfo
zstd

What is the origin and full version number of your bootloader (GRUB or other)?

GRUB 2.06 via Gentoo Linux: sys-boot/grub:2.06-r1 (https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.06-r1.ebuild)

If your SHIM launches any other components, please provide further details on what is launched.

SHIM only launches GRUB.

If your GRUB2 launches any other binaries that are not the Linux kernel in SecureBoot mode, please provide further details on what is launched and how it enforces Secureboot lockdown.

GRUB only launches Linux kernel.

If you are re-using a previously used (CA) certificate, you will need to add the hashes of the previous GRUB2 binaries exposed to the CVEs to vendor_dbx in shim in order to prevent GRUB2 from being able to chainload those older GRUB2 binaries. If you are changing to a new (CA) certificate, this does not apply.

Please describe your strategy.

We use a new EV certificate.

How do the launched components prevent execution of unauthenticated code?

SHIM

Verifies the signature of GRUB via our EV certificate before loading it
Only loads MokManager and fallback binaries built by us together with the SHIM (see ENABLE_SHIM_CERT=1), they are not shipped with shim

GRUB

Verifies the Linux kernel via the shim_lock verifier before loading it
In addition to the shim_lock verifier for the Linux kernel, all files loaded by GRUB are verified via the PGP verifier (see pgp-exit-on-verification-failure.patch in the README.md in our shim-review fork for more details on our modifications to abort the boot process if verification fails)
Module loading has been disabled, GRUB is shipped as one binary, grub.cfg is signed and embedded in the GRUB binary, a bootloader password is used to prevent tampering with the configuration and execution of commands via GRUB cmdline

Kernel

Only loads modules signed by us
Only executes binaries with a valid IMA signature created by us

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No, GRUB uses the shim_lock verifier to ensure that only kernels signed by us are loaded.

What kernel are you using? Which patches does it includes to enforce Secure Boot?

We use kernel 5.14 as default and 5.10, 5.4, 4.14 for legacy hardware support.

5.14, 5.10 and 5.4 natively include the upstream lockdown functionality, 4.14 is patched with the Debian lockdown patches (https://salsa.debian.org/kernel-team/linux/-/tree/6c9c81696618874465c51db0019195a501e4910e/debian/patches/features/all/lockdown) and the upstream commits 1957a85b0032a81e6482ca4aab883643b8dae06e and 75b0cea7bf307f362057cc778efe89af4c615354.

All kernels enforce that only modules signed by us are loaded and that only binaries with a valid IMA signature created by us are executed.

What changes were made since your SHIM was last signed?

We updated from version 15.0 to the current release (15.5) since our last shim was signed by Microsoft.
We started with upstream shim and only applied a minimal set of patches for security and compatibility reasons.
We include 3 custom patches that enforce secure mode and disable allowlist functionality and dynamic second stage loader detection (see the What patches are being applied and why section of README.md in our shim-review fork).

What is the SHA256 hash of your final SHIM binary?

f5218a973dd055437ebc5bf762ebb58a0a0163f6cbf7eb5075a5aeff840cb648

The text was updated successfully, but these errors were encountered:

julian-klode · 2022-02-28T11:06:21Z

We are not aware of any shim 15 having been signed, the previous submissions were #70 which was rejected and #225 was withdrawn, so this is considered a new vendor submission (please check your answers and update accordingly with correct detailed information), and will need contact verification, but I don't have resources to start it yet.

ecos-platypus · 2022-02-28T11:26:22Z

@julian-klode Thank you for your feedback.

In #70, the shim-review members left the decision to sign the shim to Microsoft (marked as custom second stage due to invasive changes to shim and GRUB verification, the verifier framework did not exist back then). After custom review, Microsoft signed our 15.0 shim. Since newer GRUB versions support robust verification methods via the verifier framework and the shim-lock and pgp verifiers, we dropped our custom verification methods and only apply minimal patches (that are described in README.md) to the upstream code.

For the sake of transparency, we answered the questions with regards to our last shim signed by Microsoft. Is that the issue the bug label refers to or have you encountered other issues with our submission?

ecos-platypus · 2022-03-14T09:04:43Z

@julian-klode I attached the shim binary signed by Microsoft back in 2019 as proof (shimx64.tar.gz). You can use hexdump -Cv to verify that it is the signed version of the unsigned shim submitted in #70 apart from the Microsoft signature.

Regarding the impact of whether we got a shim signed before or not on the further review:

Contact verification has to proceed anyways as the security contacts changed. I took over as main security contact and our CTO became the secondary security contact (with a new PGP key).
Security-wise it does not make a difference. We use a new code signing certificate so that vulnerable versions of GRUB cannot be loaded by the new shim.

While I personally think the submission is more transparent the way it is, I can rephrase the submission as if Microsoft never signed our shim if that is desired on your end.

ecos-platypus · 2022-03-28T07:41:45Z

@julian-klode Over the last weeks, I reviewed the pending shim requests of other vendors to support the review team as recommended by @frozencemetery in several of those issues (e.g., #226 (comment)).
Is there anything else we can do to speed up the review process for our shim?

julian-klode · 2022-03-30T11:01:56Z

I hope to get back to reviewing new vendors in May, at the moment I just wave through easy updated submissions.

ecos-platypus · 2022-05-12T09:29:10Z

@julian-klode ISSUE_TEMPLATE.md and README.md have changed since the issue was created. In February, I incorporated some changes. While reviewing recent shim requests, I noticed that further changes to both files have been made since then: The ISSUE_TEMPLATE.md has been shortened to two questions and there were minor changes to README.md in 25247e7. Do you prefer the new format or should we keep the issue as it is for the time being?

ecos-platypus · 2022-06-08T07:45:25Z

We close this request due to the new CVEs in shim and GRUB that were disclosed in the last 24 hours. We will shortly resubmit with shim 15.6 that addresses the shim security issues.

ecos-platypus mentioned this issue Feb 17, 2022

Shim 15.4 for ECOS Technology GmbH #225

Closed

9 tasks

julian-klode added new vendor This is a new vendor bug Problem with the review that must be fixed before it will be accepted contact verification needed Contact verification is needed for this review labels Feb 28, 2022

ecos-platypus closed this as completed Jun 8, 2022

miray-tf mentioned this issue Jun 28, 2022

Shim 15.6 for ECOS Technology GmbH #243

Closed

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Shim 15.5 for ECOS Technology GmbH #228

Shim 15.5 for ECOS Technology GmbH #228

ecos-platypus commented Feb 17, 2022 •

edited

Loading

julian-klode commented Feb 28, 2022 •

edited

Loading

ecos-platypus commented Feb 28, 2022

ecos-platypus commented Mar 14, 2022

ecos-platypus commented Mar 28, 2022

julian-klode commented Mar 30, 2022 •

edited

Loading

ecos-platypus commented May 12, 2022

ecos-platypus commented Jun 8, 2022

Shim 15.5 for ECOS Technology GmbH #228

Shim 15.5 for ECOS Technology GmbH #228

Comments

ecos-platypus commented Feb 17, 2022 • edited Loading

What organization or people are asking to have this signed?

What product or service is this for?

Please create your shim binaries starting with the 15.5 shim release tar file: https://github.com/rhboot/shim/releases/download/15.5/shim-15.5.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.5 and contains the appropriate gnu-efi source.

Please confirm this as the origin your shim.

What's the justification that this really does need to be signed for the whole world to be able to boot it?

How do you manage and protect the keys used in your SHIM?

Do you use EV certificates as embedded certificates in the SHIM?

If you use new vendor_db functionality, are any hashes allow-listed?

If yes: for what binaries?

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

"Please specifically confirm that you add a vendor specific SBAT entry for SBAT header in each binary that supports SBAT metadata ( grub2, fwupd, fwupdate, shim + all child shim binaries )" to shim review doc ?

Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim

Where your code is only slightly modified from an upstream vendor's, please also preserve their SBAT entries to simplify revocation.

Were your old SHIM hashes provided to Microsoft ?

What exact implementation of Secureboot in grub2 ( if this is your bootloader ) you have ?

* Upstream grub2 shim_lock verifier or * Downstream RHEL/Fedora/Debian/Canonical like implementation ?

Which modules are built into your signed grub image?

What is the origin and full version number of your bootloader (GRUB or other)?

If your SHIM launches any other components, please provide further details on what is launched.

If your GRUB2 launches any other binaries that are not the Linux kernel in SecureBoot mode, please provide further details on what is launched and how it enforces Secureboot lockdown.

Please describe your strategy.

How do the launched components prevent execution of unauthenticated code?

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

What kernel are you using? Which patches does it includes to enforce Secure Boot?

What changes were made since your SHIM was last signed?

What is the SHA256 hash of your final SHIM binary?

julian-klode commented Feb 28, 2022 • edited Loading

ecos-platypus commented Feb 28, 2022

ecos-platypus commented Mar 14, 2022

ecos-platypus commented Mar 28, 2022

julian-klode commented Mar 30, 2022 • edited Loading

ecos-platypus commented May 12, 2022

ecos-platypus commented Jun 8, 2022

ecos-platypus commented Feb 17, 2022 •

edited

Loading

julian-klode commented Feb 28, 2022 •

edited

Loading

julian-klode commented Mar 30, 2022 •

edited

Loading