Bug 1736862 (CVE-2019-14575)

Summary:	CVE-2019-14575 edk2: DxeImageVerificationHandler() fails open in case of dbx signature check
Product:	[Other] Security Response	Reporter:	Riccardo Schirone <rschiron>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	areis, berrange, crobinso, jmaloy, kraxel, lersek, pbonzini, philmd, security-response-team, virt-maint, virt-maint
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-25 09:56:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1747935, 1747936, 1801269, 1801270
Bug Blocks:	1736864

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:
https://bugzilla.tianocore.org/show_bug.cgi?id=1608