built-in shell still present in AAVMF secboot image

[dann frazier]

[ Impact ]

 * As a response to CVE-2023-48733 / LP: #2040137, we removed the UEFI Shell from Secure Boot OVMF images.

 * Unfortunately the AAVMF build code does not respect the flag that was used to
   do this, and hence AAVMF remains vulnerable to Shell based Secure Boot
   bypasses.

 * This issue is now know as CVE-2025-2486.

 * In response to CVE-2023-48733, a different patch was backported to Jammy and Focal, that merely disables the Shell, but does not remove it, which did apply to AAVMF as well, hence only Noble, Oracular, and Plucky are vulnerable.

 * Plucky is getting changed to fully remove the Shell from Secure Boot AAVMF images.

 * For Noble and Oracular the Jammy patch that disables the Shell will be forward ported.

[ Test Plan ]

 * Verify that AAVMF on Noble and Oracular no longer allows launching the Shell with Secure Boot enabled.

[ Where problems could occur ]

 * If someone is using the UEFI Shell with Secure Boot enabled in AAVMF on Noble and Oracular, their usecase will break, but unfortunately breaking such usecases is required to mitigate CVE-2025-2486.

Preserving the original bug report below:
===============================================================================
I discovered that our qemu-efi-aarch64 package (src:edk2) is still susceptible to CVE-2023-48733. That was bug 2040137. noble and oracular are vulnerable, jammy is not vulnerable, due to a different mitigation method. For jammy, we left the shell in the images, but we added code to refuse to start it if Secure Boot was enforcing. That code works for both X86 and AAVMF.

The mitigation for noble was to build the secboot images without a built-in UEFI shell by setting the build flag -DBUILD_SHELL=FALSE. While this worked for X86 (ovmf), it turns out that the AAVMF (arm64) image build did not respect that flag. Upstream recently began respecting this flag for AAVMF builds as a side-effect of this change:

  https://github.com/tianocore/edk2/commit/cb672a8eb10ff48b385b53c5fd13e7f175efa94d

The first upstream release containing that is edk2-stable-202502, which is now in plucky-proposed.

This came to my attenion while packaging this new upstream release. One of the dep-8 tests started to fail - and upon investigation, I realized it *should* have been failing the entire time.

The runes for this are public, but the security impact is not explicitly mentioned. I uploaded the new upstream to Debian last weekend, and I fixed the test case with a vague changelog entry:

https://salsa.debian.org/qemu-team/edk2/-/commit/93a2f10eb39a94dc744da0968ac6552e41265383

A user has since reported an issue about the Shell going away:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099424
One reading that with the right context might deduce that a previous release may suffer from this vulnerability.

I think the easiest thing to do would be to forward port the jammy mitigation forward. We may want to guard it to not apply to X86, because users may have decided to enable SecureBoot on ovmf with a non-secboot image. I have updated dep-8 tests in my local tree that we could add as well that explicitly test that the shell is not available in secboot images.

[Mate Kukri (mkukri)]

Forward porting the mitigation sounds fine to me, then I guess we should fully get rid of the shell from secboot AAVMF in unstable and plucky+1.

[dann frazier (dannf)]

> Forward porting the mitigation sounds fine to me, then I guess we should fully get rid of the shell from secboot AAVMF in unstable and plucky+1.

Already done in unstable/plucky due to the upstream change which now respects -DBUILD_SHELL as a side effect. I have prepared updated tests to validate that no shell is present, as well as some documentation updates. But I wanted to check if there is a desire for an embargo before I push. Seems like we should also allocate a new CVE.

[Mate Kukri (mkukri)]

I will forward this to the security team.

[Seth Arnold (seth-arnold)]

Please use CVE-2025-2486 for this issue.

Are we using this for the upstream edk2 flaw in how the shell is built? Or are we using it specifically for our packages shipping with it enabled?

Thanks

[Mate Kukri (mkukri)]

Upstream considered this a configuration problem when we originally reported it for X86, so I assume this is the case here as well.

[Mate Kukri (mkukri)]

I think downstream only (Debian and Ubuntu) CVE is reasonable here. I am happy to do the Ubuntu SRUs, but maybe we should set a CRD so that the Debian uploads can be done at the same time?

[dann frazier (dannf)]

Thanks Seth and Mate! Note that Debian stable is not vulnerable because we used the same mitigation that we did for jammy, and that works for AARCH64 as well.

[Mate Kukri (mkukri)]

Hmm so is it okay with you if I just go ahead with uploading edk2 to ubuntu?

[Mate Kukri (mkukri)]

@dannf latest edk2 was stuck in proposed due to some changes breaking -kernel argument of qemu which initramfs-tools tests relied on.

I uploaded a revert of some upstream changes that fixes that issue to unblock the migration of the plucky AAVMF that removes the shell https://launchpad.net/ubuntu/+source/edk2/2025.02-3ubuntu1

I am also planning on uploading the forward ports of the jammy mitigation to noble and oracular soon (and set this bug public along with that).

[Mate Kukri (mkukri)]

Filed https://github.com/tianocore/edk2/issues/10881

[dann frazier (dannf)]

Apologies for lack of responsiveness this week - I'm out at a conference, and the wifi is shit.

> Hmm so is it okay with you if I just go ahead with uploading edk2 to ubuntu?

OK with me. I'm good to consider this public whenever you are. I'm attaching the patches I have queued for after that - I'm not sure what pieces make sense for backporting, if any.

[Mate Kukri (mkukri)]

Branches for the noble and oracular fixes are here:

https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/edk2/+git/edk2/+ref/ubuntu/noble
https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/edk2/+git/edk2/+ref/ubuntu/oracular

Seems like the SRU team wants this released as a security update instead of SRUs, so assigning accordingly...

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2024.05-2ubuntu0.3

---------------
edk2 (2024.05-2ubuntu0.3) oracular-security; urgency=medium

   * Disable the built-in Shell when SecureBoot is enabled (LP: #2101797)
   * d/tests/shell.py: Align aarch64 snakeoil tests w/ x64.
   * SECURITY UPDATE: UEFI Shell accessible in AAVMF with Secure Boot enabled
     - CVE-2025-2486

 -- Mate Kukri <email address hidden> Wed, 07 May 2025 15:51:19 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2024.02-2ubuntu0.3

---------------
edk2 (2024.02-2ubuntu0.3) noble-security; urgency=medium

  * Disable the built-in Shell when SecureBoot is enabled (LP: #2101797)
  * d/tests/shell.py: Align aarch64 snakeoil tests w/ x64.
  * SECURITY UPDATE: UEFI Shell accessible in AAVMF with Secure Boot enabled
    - CVE-2025-2486

 -- Mate Kukri <email address hidden> Fri, 21 Mar 2025 12:28:14 +0000