Bug 1219890 (CVE-2023-48733)

is public via oss-sec

The following embed UEFI shell and seem to build it, thus are affected:

- SUSE:SLE-15-SP2:Update
- SUSE:SLE-15-SP3:Update
- SUSE:SLE-15-SP4:Update
- SUSE:SLE-15-SP5:Update

However, the following codestreams also embed UEFI shell but I'm not sure if they build it:

- SUSE:SLE-12-SP2:Update
- SUSE:SLE-12-SP3:Update
- SUSE:SLE-12-SP4:Update
- SUSE:SLE-15:Update

In recent OVMF, we only embed UEFI shell with 4MB OVMF. 2MB OVMF doesn't have shell. I will check all of them.

(In reply to Carlos López from comment #0)
> Created attachment 872719 [details]
> Attached patch
> 

This patch didn't send to mainline. It makes sense because that's a workaround patch.
I will NOT backport the patch to our OVMF because it will never upstreamming.

My plan is removing UEFI shell from SUSE SMM mode ovmf (ovmf-x86_64-smm-*.bin). Because
secure boot is only and _real_ secure with SMM feature. Other ovmf version are NOT
really secure. And users alreasy aware that because we have documentation:

Reference to bsc#1217422:

The firmware interop doc also makes note of it

# @secure-boot: The firmware implements the software interfaces for UEFI
#               Secure Boot, as defined in the UEFI specification. Note
#               that without @requires-smm, guest code running with
#               kernel privileges can undermine the security of Secure
#               Boot.

> Hello,
> 
> We have identified a vulnerability resulting from an insecure default
> configuration of OVMF/AAVMF
> and similar firmware as used in Ubuntu's edk2 package, the firmware
> used by LXD, and potentially other similar software.
> 
> Said EDK2 based firmwares implement UEFI Secure Boot functionality but
> also contain a copy of the UEFI Shell,
> this gives an OS resident attacker (without physical access or
> pseudo-physical access) the ability to execute arbitrary
> code at system level, and thus the ability bypass UEFI Secure Boot.
> 
> While no proof of concept was developed, the above conclusion was
> drawn from a theoretical attack along the lines of:
> 1. The UEFI Shell has built-in functionality for unattended scripting,
> and a command (`mm`) for writing directly to physical memory, PCI
> config space, etc.
> 2. An OS resident attacker can manipulate the boot order to execute an
> arbitrary UEFI Shell script containing any Shell commands upon reboot.

In this threat model, attacker should hacked to guest OS and get root
first. Which means that game is finished. 

> 3. These commands can then write an arbitrary unsigned executable
> payload to physical memory, and take control of the instruction
> pointer by overwriting a return address or some other pointer
> resulting in unsigned code execution.
> 
> We have developed a patch (attached here) to disable the UEFI Shell
> when Secure Boot is active, and in future, we plan on removing the
> UEFI Shell from such firmware images.
> 
> The Ubuntu edk2 and LXD issue are also known as CVE-2023-48733 and
> CVE-2023-49721, and the coordinated release date was set at February
> 14th 2024 at 13:00 UTC+0.
> 
> The bugs are tracked on Launchpad as
> https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2040137 and
> https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/2040139. These URLs
> will became publicly accessible after the coordinated release date.
> 
> The TianoCore project does not consider this a vulnerability in edk2,
> as the configuration option to disable the UEFI Shell is available,
> and deciding this policy is up to downstream vendors and distributors.
> 

As the above, I will remove UEFI shell from smm OVMF in 15-SP6. For other
ovmf version, I will consider that.

After checked SUSE ovmf, we already removed shell from 2mb x86_64 ovmf and smm x86_64 ovmf since since edk2-stable202208 and earlier. And, the BUILD_SHELL=FALSE build option is not available on aarch64 and xen ovmf.

Because this CVE does not have real use case, and bypassing secure boot mainly affects x86 ovmf. So I removed shell from 4mb x86_64 ovmf in Factory first.

The change be merged to factory:

-------------------------------------------------------------------
Fri Mar 22 09:17:00 UTC 2024 - Joey Lee <jlee@suse.com>

- Removed EFI shell from 4mb x86_64 ovmf image because it has
  security concern. Removed shell can also save space of ovmf
  image. (bsc#1219890, CVE-2023-48733)
    - Updated ovmf.spec: add BUILD_SHELL=FALSE to BUILD_OPTIONS_X64
    - 2mb x86_64 ovmf and smm x86_64 ovmf are already removed
      shell since edk2-stable202208 and earlier.
    - The BUILD_SHELL build option is not available on aarch64 and xen ovmf.
    - Shell.efi still be built independently and be packaged to ovmf-tools.
      User can copy it to EFI partition for running it by firmware's boot
      manager if they still need a shell. But user should either disables
      secure boot or sign Shell.efi by himself.