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.
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.
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.
Created edk2 tracking bugs for this issue: Affects: epel-all [bug 1801270] Affects: fedora-all [bug 1801269]
Upstream bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1608