Created attachment 1459 [details] Proposed Ubuntu patch This is re GHSA-6fhj-3w4g-3vw2. The UEFI Shell provides direct access to physical memory via the "mm" command. Arbitrary physical memory writes are wildly understood to give an the ability to bypass Secure Boot. When built into a firmware image, an OS-resident attacker can launch the UEFI Shell by changing the "BoorOrder" variable. Then by placing a "startup.nsh" file on the ESP root and triggering a system reset, the attacker is able to execute arbitrary UEFI Shell commands. I became aware of this during the use of Debian and Ubuntu packaged OVMF binaries, but I believe by default the UEFI Shell is always included in builds. Fedora (and likely its derivatives such as RHEL) notable do not include the Shell. To solve this in Ubuntu and Debian, I have proposed the patch attached to this ticket, which could allow the UEFI Shell to be still built into the image, but not executed when Secure Boot is active. I suggest either: a) Integrating a similar patch into the upstream tree. (I am not adamant on patching the Shell itself, the boot manager could for instance hide the Shell option with SB enabled too) b) Disable building the UEFI Shell into Secure Boot capable images by default, and warning potential users via documentation that it is a bad idea to do so.
> I became aware of this during the use of Debian and Ubuntu packaged OVMF > binaries, but I believe by default the UEFI Shell is always included in > builds. Fedora (and likely its derivatives such as RHEL) notable do not > include the Shell. OvmfPkg has a BUILD_SHELL compile time option (added 2022), "build -D BUILD_SHELL=FALSE $otheropts" can be used to exclude the shell from firmware builds. Which is used by Fedora and RHEL when compiling the secure boot enabled builds. I'd suggest debian and ubuntu do the same. Changing upstream to not add the shell to secure boot builds makes sense. Unfortunately it is not that easy because CI expects the shell being present, removing it breaks test cases. So we need figure some alternative for CI first.
Oh, fixing CI turned out to be easy: https://github.com/kraxel/edk2/commits/devel/shell/
Created attachment 1462 [details] 0001-OvmfPkg-only-add-shell-to-FV-in-case-secure-boot-is-.patch Patch to actually fix the bug (on top of the series linked in the previous comment).
Agreed, that's a lot better solution for upstream, and I am hoping Debian/Ubuntu can eventually do that. I don't really think this CVE strictly speaking affects the upstream codebase, we've mainly wanted the bad default configuration changed. The reason for the patch I've attached is unfortunately current Debian/Ubuntu packaging uses the Shell for initial key enrollment for Secure Boot builds and requires BuildShell==TRUE. This might very well change in the future, but for backporting to stable releases, the patch I've proposed could avoid changing a lot of logic churn around that.
(In reply to Mate Kukri from comment #4) > Agreed, that's a lot better solution for upstream, and I am hoping > Debian/Ubuntu can eventually do that. I don't really think this CVE strictly > speaking affects the upstream codebase, we've mainly wanted the bad default > configuration changed. > The reason for the patch I've attached is unfortunately current > Debian/Ubuntu packaging uses the Shell for initial key enrollment for Secure > Boot builds and requires BuildShell==TRUE. No. It's also possible to create an bootable iso image with shell.efi + enrolldefaultkeys.efi for that purpose. Alternative approach: use https://gitlab.com/kraxel/virt-firmware > This might very well change in the future, but for backporting to stable > releases, the patch I've proposed could avoid changing a lot of logic churn > around that. Yes, might make sense. I'm not familiar with the ubuntu/debian packaging process, so I'm not going to suggest how to fix that, I'm only showing options ;) (feel free to copy that over to launchpad, I have to access to the bug there).
Hi, Just letting you know that we have set the Ubuntu CRD at: February 14th at 13:00 UTC+0.
Discussed in Tianocore Infosec meeting 2/7/2024. Inclusion of UEFI shell is a platform policy choice by vendors. Tianocore Infosec decided not to publish an advisory for this. Vendors may publish their own advisory. MS has prohibited UEFI Shell inclusion in the logo doc like the public one https://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf "15. UEFI Shells and related applications. UEFI Modules that are not required to boot the platform must not be signed by any production certificate stored in "db", as UEFI applications can weaken the security of Secure Boot. For example, this includes and is not limited to UEFI Shells as well as manufacturing, test, debug, RMA, & decommissioning tools. Running these tools and shells must require that a platform administrator disables Secure Boot."
> Just letting you know that we have set the Ubuntu CRD at: February 14th at > 13:00 UTC+0. We are past that time. Can the bug made public now? Is there an advisory? Can't see anything here: https://ubuntu.com/security/notices
I believe so, I have sent an email about this to oss-security, and unembargoed the LaunchPad bugs as well.
Ok, unticked 'Security group for Tianocore' checkbox. Refreshed shell patch series (including comment #3 patch now). https://github.com/kraxel/edk2/commits/devel/shell/
