Bug 1736862 (CVE-2019-14575) - CVE-2019-14575 edk2: DxeImageVerificationHandler() fails open in case of dbx signature check
Summary: CVE-2019-14575 edk2: DxeImageVerificationHandler() fails open in case of dbx ...
Alias: CVE-2019-14575
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1801270 1747935 1747936 1801269
Blocks: 1736864
TreeView+ depends on / blocked
Reported: 2019-08-02 08:26 UTC by Riccardo Schirone
Modified: 2021-10-25 09:56 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-10-25 09:56:13 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
TianoCore 1608 0 None None None 2019-08-02 22:16:29 UTC

Description Riccardo Schirone 2019-08-02 08:26:01 UTC
Function DxeImageVerificationHandler() does not properly check whether an unsigned EFI file should be allowed or not. If a .efi image is both in the whitelist and in the blacklist, it is not supposed to load but if certain operations fail it will be loaded anyway, thus bypassing the verification.

DxeImageVerificationHandler() has specific code to handle .efis that aren't signed, but should be allowed to run. To do this, it hashes the .efi image, and then compares the image against a blacklist (dbx) and a whitelist (db). A situation could occur where a hash is both in the dbx and db list. This is supposed to fail. since it's in the dbx list. Because of the way a signature is looked up in dbx (using IsSignatureFoundInDatabase() return value) any failure (e.g. allocation failure, looking up the variable failure, ...) will be seen as signature not found in database. This logic allows for bypassing the dbx looking and loading of an unsigned .efi image that should not be loaded.

Comment 3 Riccardo Schirone 2019-09-02 09:55:24 UTC
As per discussion by email with Laszlo:

Attack Vector: Adjacent as a UEFI binary could be downloaded from the local ethernet segment, by using TFTP. HTTP/HTTPS is not enabled on ovmf/edk2 packages shipped in RHEL, so a Network vector is not possible.
Attack Complexity: High as the attacker needs to make the function IsSignatureFoundInDatabase fail somehow (e.g. allocation failure)
Privileges Required: None as the attacker could just inject packages in the local ethernet segment, without having any privilege on the impacted system.
User Interaction: None as it is common for virtual machines to boot/reboot automatically in response to load spikes.
Scope: Unchanged
Confidentiality/Integrity/Availability: High as an attacker who could load a malicious EFI binary could execute whatever he wants on the system.

Comment 4 Riccardo Schirone 2019-09-02 10:00:58 UTC
The attack requires another infected machine on the network where the virtual machine with OVMF/edk2 is connected, to be able to hijack the loading of a EFI binary from the local network segment. If the attacker does not have that, he would need high privileges to be able to write some files to the EFI partition on the impacted system. For these reasons, the attack does not seem that critical and the Impact is set to Moderate.

Comment 13 Riccardo Schirone 2020-02-10 14:31:59 UTC
Created edk2 tracking bugs for this issue:

Affects: epel-all [bug 1801270]
Affects: fedora-all [bug 1801269]

Comment 14 Riccardo Schirone 2020-02-10 14:40:56 UTC
Upstream bug:

Note You need to log in before you can comment on or make changes to this bug.