Unable to update DBX data base for UEFI

mdcTUX · February 9, 2024, 6:24am

The DBX database which contains the black listed boot loaders can’t be updated.
fwupdmgr can’t install it. The current one will be version 371. But VMware for example only provide version 77. The manual update will fail’s because of an to old version of fwupd. But the update are very important , because many CVE’s are fixes with it.
https://fwupd.org/lvfs/devices/org.linuxfoundation.dbx.x64.firmware

curl -o /tmp/x.cab "https://fwupd.org/downloads/fc3feb015df2710fcfa07583d31b5975ee398357016699cfff067f422ab91e13-DBXUpdate-20230509-x64.cab"
fwupdmgr get-details /tmp/x.cab
Decompressing…           [  -                                    ]
VMware, Inc. VMware7,1
│
└─UEFI dbx:
  │   Device ID:          362301da643102b9f38477387e2193e57abaa590
  │   Summary:            UEFI revocation database
  │   Description:        
  │   Updating the UEFI dbx prevents starting EFI binaries with known security issues.
  │   Current version:    77
  │   Minimum Version:    77
  │   Vendor:             UEFI:Linux Foundation
  │   Install Duration:   1 second
  │   Update Error:       Not compatible with org.freedesktop.fwupd version 1.8.16, requires >= 1.9.1
  │   GUIDs:              c6682ade-b5ec-57c4-b687-676351208742
  │                       f8ba2887-9411-5c36-9cee-88995bb39731
  │   Device Flags:       • Internal device
  │                       • Needs a reboot after installation
  │                       • Device is usable for the duration of the update
  │                       • Updatable
  │                       • Only version upgrades are allowed
  │                       • Signed Payload
  │ 
  └─Secure Boot dbx:
        New version:      371
        Summary:          UEFI Secure Boot Forbidden Signature Database
        Variant:          x64
        License:          Proprietary
        Size:             21.2 kB
        Urgency:          High
        Release Flags:    • Trusted payload
                          • Trusted metadata
        Description:      
        Insecure versions of the Microsoft Windows boot manager affected by Black Lotus were added to the list of forbidden signatures due to a discovered security problem. This updates the dbx to the latest release from Microsoft.
        
        Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures. Applying this update may also cause some Windows install media to not start correctly.
        Issue:            CVE-2022-21894

So how can such very important be installed?

jlehtone · February 9, 2024, 8:32am

The fwupd.org site lists many versions of DBX between 77 and 371. Which is the latest that could be installed with 1.8.16? The 371 lists only one CVE?

RHEL did rebase fwupd to 1.8.16 in 9.3 and had 1.8.10-based version in 9.2. Curiously, the CentOS Stream 9 that is supposedly a preview to future RHEL 9 still has only 1.8.10 in its repo. Therefore, one cannot predict what RHEL 9.4 will have. Anyway, it is up to Red Hat to rebase the fwupd in EL.

The threat is that someone sneaks into your system a tampered or vulnerable bootloader/kernel, isn’t it?
The proper Secure Boot would guard against booting with those. You say: “very important” so it is easy to inject such stuff into your systems?

mdcTUX · February 9, 2024, 9:03am

371 will fix CVE-2022-21894
220 will fix CVE-2023-28005
217 will fix CVE-2022-34303, CVE-2022-34302, CVE-2022-34301

and so on.
The full change log can found when scrolling the first link.
So I think it will be an big problem.

jlehtone · February 9, 2024, 9:41am

The second to last, the 220, does not show “Update Error”:

# fwupdmgr get-details DBXUpdate-20230314-x64.cab
Decompressing…           [  -                                    ]
HP HP EliteDesk 800 G4 WKS TWR
│
└─UEFI dbx:
  │   Device ID:          362301da643102b9f38477387e2193e57abaa590
  │   Summary:            UEFI revocation database
  │   Description:        
  │   Updating the UEFI dbx prevents starting EFI binaries with known security issues.
  │   Current version:    77
  │   Minimum Version:    77
  │   Vendor:             UEFI:Linux Foundation
  │   Install Duration:   1 second
  │   GUIDs:              95641a6b-bc03-5b8b-bdfc-c92dab523a06
  │                       7689caf4-c147-5c67-bff9-5dbe59a441bd
  │                       c6682ade-b5ec-57c4-b687-676351208742
  │                       f8ba2887-9411-5c36-9cee-88995bb39731
  │   Device Flags:       • Internal device
  │                       • Updatable
  │                       • Needs a reboot after installation
  │                       • Device is usable for the duration of the update
  │                       • Only version upgrades are allowed
  │                       • Signed Payload
  │ 
  └─Secure Boot dbx:
        New version:      220
        Summary:          UEFI Secure Boot Forbidden Signature Database
        Variant:          x64
        License:          Proprietary
        Size:             13,9 kB
        Urgency:          High
        Release Flags:    • Trusted payload
                          • Trusted metadata
        Description:      
        Insecure versions of software from Trend Micro, vmware, CPSD, Eurosoft, and New Horizon Datasys Inc were added to the list of forbidden signatures due to discovered security problems. This updates the dbx to the latest release from Microsoft.
        
        Before installing the update, fwupd will check for any affected executables in the ESP and will refuse to update if it finds any boot binaries signed with any of the forbidden signatures.
        Issue:            CVE-2023-28005

If you apply the 220 now, then you lack only the CVE-2022-21894?

mdcTUX · February 9, 2024, 9:52am

After applying the old update, the database now on 217. But all current and features updates can’t applied.

fwupdmgr get-devices 362301da643102b9f38477387e2193e57abaa590
VMware, Inc. VMware7,1
│
└─UEFI dbx:
      Device ID:          362301da643102b9f38477387e2193e57abaa590
      Summary:            UEFI revocation database
      Current version:    217
      Minimum Version:    217
      Vendor:             UEFI:Linux Foundation
      Install Duration:   1 second
      GUIDs:              c6682ade-b5ec-57c4-b687-676351208742 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503
                          f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64
      Device Flags:       • Internal device
                          • Updatable
                          • Needs a reboot after installation
                          • Device is usable for the duration of the update
                          • Only version upgrades are allowed
                          • Signed Payload

Ritov · February 9, 2024, 1:25pm

It will have at least >= 1.9.12.

Ritov · February 9, 2024, 1:26pm

I suggest to not install the latest DBX data, if you do not want to lock you out. Wait until RL delivers a new shim package …

mdcTUX · February 12, 2024, 5:12am

@Ritov this can’t happens, because the update will check, that you don’t use an boot loader which are on the new black list.

iwalker · February 12, 2024, 6:43am

You will have to wait, as you have already been told, for RHEL to release the update, and for Rocky to then release the update.

jlehtone · February 12, 2024, 8:51am

How does it do that? How does in know which bootloader was used to boot the system?

mdcTUX · February 12, 2024, 9:10am

As far as I know it will use efibootmgr.
Here you will see an sample output, when the current loader will be blocked.

system · April 12, 2024, 9:10am

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.