baramundi shim 15.4 20210811

[ghost]

Make sure you have provided the following information:

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

What organization or people are asking to have this signed:

baramundi software AG

What product or service is this for:

baramundi Management Suite

Please create your shim binaries starting with the 15.4 shim release tar file:

https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.4 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 SHIM bootloader starts a grub2 which decides if it should boot the local installed windows operating system or netboot a windows PE image.
This is necessary to support remote operating system installation on clients in the LAN.
With a signed SHIM bootloader we are able to support clients with enabled secure boot feature.

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

Private key is stored in hardware module with controlled access.

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

Yes

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

vendor_db not used, no hashes allow-listed

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

No Linux kernel is used

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
The grub2 sources we use have it's origin in the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

"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

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

grub:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/
grub.ubuntu,1,Ubuntu,grub2,2.04-1ubuntu44.2,https://www.ubuntu.com/
grub.baramundi,1,Baramundi,grub2,2.04-1ubuntu44.2-bblefi1,https://github.com/baramundisoftware/grub2

Were your old SHIM hashes provided to Microsoft ?

No. We changed the EV certificate embedded in the shim, so the old shim can only start grubs signed with the old ev certificate.

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 used a new EV certificate which is only used for the new grub 2.04 which origin is the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

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 ?

Downstream RHEL/Fedora/Debian/Canonical like implementation
see: https://github.com/baramundisoftware/grub2

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

grub 2.04 (extended) see: https://github.com/baramundisoftware/grub2
The grub2 sources we use have it's origin in the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

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

Our shim only launches the mentioned grub 2.04

If your GRUB2 launches any other binaries that are not Linux kernel in SecureBoot mode,

please provide further details on what is launched and how it enforces Secureboot lockdown

The SHIM bootloader starts a grub2 which decides if it should boot the local installed windows operating system or netboot a windows PE image.
This is necessary to support remote operating system installation on clients in the LAN.
With a signed SHIM bootloader we are able to support clients with enabled secure boot feature.

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.

No certificate got reused. The EV certificate used for the shim is new. No need for vendor_dbx entry.

How do the launched components prevent execution of unauthenticated code?

with standard grub 2.04 functionality, we prevent to start any unsigned bootloader

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

No

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

We launch Windows and Windows PE loader and kernel

What changes were made since your SHIM was last signed?

no changes were made to the original shim

What is the SHA256 hash of your final SHIM binary?

shim_x64.efi SHA256 Hash:

397E6D03A862C6D269F6E27B93A2C39B0652F5FF203158FDDA7C8CB057AC1654

[frozencemetery]

Previous review was #130

[frozencemetery]

Apologies for the noise. Here's my actual review:

Things okay:

• This counts as a new vendor since previous review didn't complete. I have not verified emails.
• Build reproduced locally
• shim is from a commit on main; gnu-efi from 15.4 branch
• Certificate looks okay

Things not okay:

• SBAT does not match what is stated in issue

Questions:

• How is your private key protected?

[ghost]

Hi, thanks a lot for reviewing and for your feedback.

We corrected SBAT entries for the grub2 and updated this issue.
see: https://github.com/baramundisoftware/grub2/blob/main/debian/sbat.csv.in
We also checked the SBAT entries used for shim, these should be ok.

Our private key for the ev-certificate is stored on a hardware dongle, protected with a password. The dongle is securely stored in a safe. Only the devs working on the bootloader have access to it.

[frozencemetery]

I'm unable to verify emails - PGP keys are not available.

[ghost]

Hi again,

you're right, I added the pgp key to the review-repository and updated the readme.

Name: Simon Förg
Position: Software Developer
Email address: simon.foerg@baramundi.com
PGP key, signed by the other security contacts, and preferably also with signatures that are reasonably well known in the linux community: https://github.com/baramundisoftware/shim-review/blob/baramundi-shim-20210811/2483E061F86E7214_simon.foerg%40baramundi.com.asc

Thanks a lot and best regards.

[frozencemetery]

Okay, I see key fingerprints, but only Felix's has been pushed to a keyserver. Yours should be as well.

[ghost]

Hi and sorry for keep you waiting.
I pushed my public key to keyserver.pgp.com today.
Hope, we did everything right for now and look forward to your review.

Best regards.

[frozencemetery]

Checking today, I see Felix's key, but still not Simon's. Possibly keyserver.pgp.com doesn't sync, or maybe it choked on the umlaut - I'm not familiar with the server, and when I went to dig further, it required a captcha.

[ghost]

Hmm, I see. Today I published my public key to https://pgp.mit.edu/
Hopefully this will work. I was able to find myself and Felix.

[frozencemetery]

I do see a key there, but that has a different fingerprint than what is specified in README.md.

[ghost]

Great, glad to hear and thanks for the fast response.
You're right, sorry, I forgot updating the rest of the links in this issue after branching and adding my key. Links should be correct now, I revised this issue. Thanks for your effort.

[ecos-platypus]

The contact information is not yet in the format that is expected and described in README.md. It is stated that for both security contacts, the PGP public key fingerprint should be listed README.md (missing for simon.foerg@baramundi.com). Furthermore, each security contact has to sign the public key of the other contact and push the signed public key to the keyservers.

[ghost]

Hi and thanks a lot for your support. We have created new pgp keys, signed them and published them on keyserver.ubuntu.com. We have also updated the thumbprints in the readme. Hopefully we did everything right this time.
Looking forward to your review.

[ecos-platypus]

Disclaimer: I am not an authorized reviewer but review other shims to reduce the workload of the authorized reviewers and speed up the process for everyone.

Review was conducted in accordance to the reviewer guidelines (https://github.com/rhboot/shim/wiki/reviewer-guidelines)

1. Vendor is new, PGP keys are okay now and can be reviewed by an authorized reviewer
2. Build is reproducible
3. Shim is built from upstream branch 15.4 (commit 16eeafe28c552bca36953d75581500887631a7f1)
4. All questions in issue template and README.md are answered, however there is only a MD5 hash listed for the shim binary, not a SHA256 hash
5. Embedded EV certificate stands in relation with the company (businessCategory = Private Organization, serialNumber = HRB 2064, jurisdictionC = DE, jurisdictionST = Bayern, jurisdictionL = Augsburg, C = DE, ST = Bayern, L = Augsburg, street = Beim Glaspalast 1, O = baramundi software AG, CN = baramundi software AG)
6. Private key is stored in hardware module
7. The embedded EV certificate has a duration of 3 years which is acceptable
8. The submitted shim binaries contain the sbat data listed in the issue
   1. The shim sbat entry is missing a vendor-specific line. The baramundi vendor extension used with GRUB is sensible
   2. GRUB is derived from Ubuntu and should hence include an intermediate ubuntu grub line (see the recent request shim 15.4-0ubuntu9 for Ubuntu #197 for an ubuntu shim)
9. GRUB is used as bootloader
10. Questions regarding GRUB
11. GRUB 2.04 with Ubuntu patches
12. No custom patches
13. No Linux Kernel is loaded
14. Not applicable, first shim application
15. Shim verifies GRUB, not sure about the verification of the loaded Windows binaries by GRUB

• There are still some issues with sbat data.
• When the shim is rebuilt with new sbat data, please also replace the MD5 hash in the issue template / README.md with the SHA256 hash of the new binary.
• I cannot verify how GRUB and Windows work together to ensure a secure boot chain, I leave that to another reviewer that has more experience with the Windows boot process.

[julian-klode]

Closing outdated request due to the recent round of CVEs in grub and shim requiring a new submission with fixes for all these CVEs.