exposing the EFI shell in Secure Boot mode can lead to security bypass

[Mate Kukri]

The EFI shell is available as a built-in Boot Option in Ubuntu's OVMF builds, even when Secure Boot is enabled.

This application has known mechanisms for bypassing UEFI Secure Boot, and has already been barred from signing previously.

It should either: not be built into Secure Boot capable OVMF builds, or disabled when Secure Boot is enabled in any capacity.

[Mark Esler (eslerm)]

This vulnerability affects both edk2 and LXD.

I will add future subscribers to this bug to https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/2040139

[Mark Esler (eslerm)]

Christian, could you please add the appropriate maintainers to this private bug?

[Mark Esler (eslerm)]

(edited since issue was merged with LP#2040139)

CVE-2023-48733 describes this issue in edk2 and CVE-2023-49721 describes the implementation of this issue in lxd.

[dann frazier (dannf)]

I was just subscribed to this and bug 2040139 today, so catching up..

Disabling the integrated shell only when SecureBoot mode is active is appealing. That seems like the safest mitigation for a stable update. I don't see an existing mechanism for that though.

All of the images provided by edk2 include the secureboot code - whether or not it is enforced during boot is an EFI variable setting. For ovmf, we have a separate image tagged for secureboot that requires SMM - it is documented as the recommend image for secureboot VMs, with the other image type already noted as being less secure:
  https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/ovmf.README.Debian

Disabling the built-in shell in all images seems like a big hammer. Newer edk2 packages do provide efi-shell-* packages that contain standalone Shell.efi binaries, but it is sometimes convenient to have the shell built-in for testing things.

One option is to disable the shell in only the secureboot-tagged ovmf image, and introduce secureboot-tagged variants for the other architectures also with no integrated shell. Users would then have the non-secureboot-tagged images if they want a built-in shell. We could remove the SecureBoot code from those images to make the features of built-in Shell and the ability to enable SecureBoot mutually exclusive. But having VM firmware suddenly forget how to do SecureBoot mode after an OS update - even if it is not the firmware image we recommend for SecureBoot mode - seems like a bad experience.

[Mark Esler (eslerm)]

Thanks Dann!

@mkukri has a solution to replace the EFI shell wtih python-uefivars to enroll keys. I don't know the specifics. I believe this would require python-uefivars in main for all affected releases, which would require MIR coordination.

Having images that are clearly documented as not supporting Secure Boot sounds fine to me. This implies a threat model where a local attacker is not a concern. An option to enable EFI Shell on Secure Boot systems is also okay (say for debugging), as long as it is opt in (secure by default) and the risk is well communicated.

[dann frazier (dannf)]

Hi - yeah, I mentioned in bug 2040139 that we shouldn't need to change our enrollment method to get this fix out. That's done at build-time, and we can just use a non-secure-boot image to do it. I do plan to change the enrollment method, but that's just a general improvement we could do in a devel release.

[Christian Ehrhardt  (paelzer)]

Hi,
also just got note of this and catching up on this and bug 2040139

> @mkukri has a solution to replace the EFI shell wtih python-uefivars to enroll keys. I don't know the specifics. I believe this would require python-uefivars in main for all affected releases, which would require MIR coordination.

No, AFAICS it would only be a build time dependency right? Replacing the use of the intermal shell in edk2-vars-generator.py. Would we want this to be high quality - yes, would we want it to be in main - I guess, but just strictly looking at the rules it does not have to be in main as a pure build time dependency.

Or - as DannF said, even if we would drop the shell in the secure-boot image, we could just use the non-secure-boot image to do the enrollment. In that case also the change is smaller (which is more appealing when changing released Ubuntu versions). In that case python-uefivars would not even be needed as a build time dependency.

[Mate Kukri (mkukri)]

If the "non-secure-boot" images still have both the Shell always enabled and give the user the option to enroll their own keys and setup SB, they could still end up with Secure Boot enabled and have the shell. Of course it's somewhat better than the same with prod keys, and we can clearly label it as "not supported", but it still exposes an insecure scenario.

The point I am trying to make is that if we'd like to have both Secure Boot support and the Shell at the same time in any of the images, I think the ability to launch the shell should be gated against Secure Boot being enabled (maybe with a hopefully upstream-able patch?). Or I guess another option is to compile out secure boot support from images that have the shell.

[Mate Kukri (mkukri)]

A fairly simple and non-invasive fix I could PoC would be to patch EDK2 to only allow launching the Shell if SecureBootEnabled==0 || SecureBoot==0 || SetupMode==1.

That way key enrollment could stay identical for now, users with SB disabled would still have the shell available, and theoretically (fingers crossed) we'd get away with a small patch.

[Christian Ehrhardt  (paelzer)]

We kept discussing in two places, so I merged these as duplicated.
Have a look at bug 2040139 for some context on the LXD side of things.
From now on we will discuss it all here.

[dann frazier (dannf)]

On Wed, Dec 6, 2023 at 1:36 AM Mate Kukri <email address hidden> wrote:
>
> A fairly simple and non-invasive fix I could PoC would be to patch EDK2
> to only allow launching the Shell if SecureBootEnabled==0 ||
> SecureBoot==0 || SetupMode==1.
>
> That way key enrollment could stay identical for now, users with SB
> disabled would still have the shell available, and theoretically
> (fingers crossed) we'd get away with a small patch.

Yes, I agree that would be ideal. Is there a channel open with
upstream on this matter where we could discuss such a patch? If not,
shall we open a security bug in their bugzilla?
  https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues

[Mate Kukri (mkukri)]

> Yes, I agree that would be ideal. Is there a channel open with
> upstream on this matter where we could discuss such a patch? If not,
> shall we open a security bug in their bugzilla?
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues

That was a new idea, so I don't think there is a channel open yet, but I agree it would be ideal to open one.

[Mate Kukri (mkukri)]

Here is a proof of concept patch that disables the Shell only in SecureBoot and non-Setup mode.

I've tested this to build and correctly enroll the variables. Then when used as previously in a Secure Boot enabled VM, the Shell does not launch due to the returned EFI_SECURITY_VIOLATION.

[dann frazier (dannf)]

Thanks @mkukri!

@eslerm, as you seem to be coordinating, are you +1 with opening an upstream security bug? I can open that if you like since I already have an account, and ask them to subscribe others.

[Mark Esler (eslerm)]

Dann, we should coordinate with tianocore and Debian.

I can do this, but ideally we set a "coordinated release date" first.

[dann frazier (dannf)]

Thanks Mark. fwiw, I'm fine w/ the end of Jan timeframe for getting patches together for the edk2 package.

[Seth Arnold (seth-arnold)]

I'm worried about the "disables the Shell only in SecureBoot and non-Setup mode" approach.

What are the "known mechanisms" to use the Shell to bypass Secure Boot?

Would any of these mechanisms persist through the following process?

- attacker reboots system and enters "bios" setup
- attacker disables secure boot
- attacker boots into Shell
- attacker fiddles the knobs
- attacker reboots system and and enters "bios" setup
- attacker enables secure boot
- attacker bypasses Secure Boot due to the knob fiddling

Thanks

[Julian Andres Klode (juliank)]

That's fine Seth if secure boot is disabled you can pretty much fiddle the knobs from everywhere.

If you turn it to setup mode you can conveniently replace the keys from inside Linux too.

It mostly boils down to the efi shell being easy to manipulate over the serial console by a script whereas to go into uefi and toggle secure boot off you'd likely have to be human or do some machine learning to recognise the screens (or toggle stuff blindly).

Outside of FDE the effects probably are negligible because it's much easier to attack the systems by booting them with init=/bin/bash and just rootkit the OS...

[Mate Kukri (mkukri)]

@seth-arnold The known mechanism is full access to physical memory via Shell commands, which can be turned into arbitrary code execution. However if you have the ability to go through that process you can also just run any unsigned binary after step 2 instead of having to use the Shell, I don't think it gets you any extra abilities over simply launching unsigned code.

@juliank If you have root access, you can also drop a script for the EFI shell on the ESP, change the boot order to it then trigger a reboot. After the reboot the shell script can launch a payload that runs a backdoored OSes, etc. FDE is hopefully fine if launching the Shell affects TPM measurements.

I think the issue here is arbitrary unsigned code execution without someone having access to an external console. E.g. similar to previous things tagged bypasses to Secure Boot.

[Mark Esler (eslerm)]

CVE-2023-48733 describes this issue in edk2 and CVE-2023-49721 describes the implementation of this issue in lxd.

[Seth Arnold (seth-arnold)]

Julian, Mate, thanks. That does sound like a more complex implementation is a fair choice to make.

That leaves me with one new worry:

> disables the Shell only in SecureBoot and non-Setup mode

Are we enumerating environments where Shell is disabled? Or are we enumerating environments where Shell is enabled?

Thanks

[Mate Kukri (mkukri)]

@seth-arnold The patch proposed here patches the Shell binary to exit with "EFI_SECURITY_VIOLATION" if the following condition is true: "SecureBootEnabled() && !SetupMode".

I suppose it is closer to "enumerating environments where Shell is disabled", but I also believe it is sufficient to restrict access to Shell to environments where unsigned code execution was allowed anyhow.

[dann frazier (dannf)]

Hi Mark - have you begun coordination w/ upstream? I'd like their perspective on our approach. Also, I assume that Incus is vulnerable as well. Have we reached out to them?

[Mark Esler (eslerm)]

Hi Dann, I have not coordinated yet. The CRD is loose, is there a specific date we can commit to? edk2 may have their own timeline, but I can reach out for their perspective. January 2nd may be a better date to initiate this conversation.

Downstreams and other vendors will be contacted after we have a solid patching plan and timeline. So far this includes Debian and (once verified) Incus.

Seth, does this sound good to you? If so I will file a report on https://github.com/tianocore/edk2/security and add you, Dann, and Mate. And offer to add their security devs to this bug.

[dann frazier (dannf)]

On Thu, Dec 14, 2023 at 11:15 AM Mark Esler <email address hidden> wrote:
>
> Hi Dann, I have not coordinated yet. The CRD is loose, is there a
> specific date we can commit to? edk2 may have their own timeline, but I
> can reach out for their perspective. January 2nd may be a better date to
> initiate this conversation.

I'd prefer not to commit to a date before upstream is engaged. My
concern is that they may prefer a different approach or spot
additional issues that we should take into account, and that may take
more time. As noted in Comment #16, I'm OK with a date at the end of
January for the edk2 deb part, assuming Mate's approach is the
approach we agree to take. That seems straightforward, other than
removing some shell dependencies from the autopkgtests, which I plan
to spend some time on over the holidays.

> Downstreams and other vendors will be contacted after we have a solid
> patching plan and timeline. So far this includes Debian and (once
> verified) Incus.

Sounds good.

> Seth, does this sound good to you? If so I will file a report on
> https://github.com/tianocore/edk2/security and add you, Dann, and Mate.
> And offer to add their security devs to this bug.

Note that their docs say to file security bugs in their bugzilla
instance, not github:
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues

My bugzilla account there is under <email address hidden>.

   -dann

[Mark Esler (eslerm)]

Thanks Dann! I mistook the "Suggest A Policy" button for something else.

Due to `Tianocore Security Issue product are only visible to the Reporter` would you prefer to be the contact? If so, please include the CVD-ID, that our CRD is late January/early February and that Mate discovered this issue.

I'll ping LXD.

[Mark Esler (eslerm)]

Dann, I'd rather report this through their GitHub's Report a Vulnerability feature https://github.com/tianocore/edk2/security

EDK II enabled this feature for reporting, and it is a better platform for all of us to communicate with them.

I can file a bug noting the discrepancy in their reporting policies, and followup on bugzilla to direct their other devs to the GHSA issue.

[dann frazier (dannf)]

On Thu, Dec 14, 2023 at 12:30 PM Mark Esler <email address hidden> wrote:
>
> Dann, I'd rather report this through their GitHub's Report a
> Vulnerability feature https://github.com/tianocore/edk2/security
>
> EDK II enabled this feature for reporting, and it is a better platform
> for all of us to communicate with them.
>
> I can file a bug noting the discrepancy in their reporting policies, and
> followup on bugzilla to direct their other devs to the GHSA issue.

+1, thanks.

[Mark Esler (eslerm)]

upstream report was made to https://github.com/tianocore/edk2/security/advisories/GHSA-6fhj-3w4g-3vw2#advisory-comment-92555 with a request to add Dann and Mate

[Mate Kukri (mkukri)]

@eslerm thanks for reporting this upstream, will follow-up to any discussion when I get added.

Just keep in mind that this isn't a vulnerability in upstream edk2 codebase in the strict sense, as it only affects you if you specifically opt-in to certain configurations in your builds. These being insecure should really be documented by upstream to avoid others falling into the trap however.

[Mark Esler (eslerm)]

Thanks Mate. I relayed what you said for upstream.

I'll rely on you and Dann for technical expertise. I'll mostly help mediate conversations and agreements.

Dangerous opt-ins (or combination of opt-ins) should be documented. Could you share an example of this documentation? (after the break is fine!)

Perhaps we need to report this through the distros list if many downstreams are affected.

[Mate Kukri (mkukri)]

@eslerm

I think in this case it is something like:
 "Enabling the UEFI Shell in OVMF builds that also support Secure Boot isn't recommended, the Shell can be used to bypass Secure Boot."

However, if my patch (or something similar) gets upstreamed, the warning would no longer be valid, as the patch prohibits executing the UEFI Shell when Secure Boot is enabled.

(And just noting that I still don't have access to the upstream advisory.)

[Mate Kukri (mkukri)]

And as far as effected distros go, so far I've confirmed:

- OVMF on Fedora, Red Hat (and likely derivatives): not affected
- OVMF and LXD on Debian, Ubuntu (and likely derivatives): affected

Other distros are still up in the air.

[Mark Esler (eslerm)]

@mkukri: Sorry. I meant, could you share an example of their current documentation? If you send specifics, I can review.

I like giving users the option to do something "unsafe". It might be safe or necessary in their user case, or they might have other reasons to justify their threat model. As long as safe defaults are used and the documentation clearly communicates risks I'm happy.

We could share patches 1 week before CRD on oss-security's distros list, and reach out to other vendors we know about then (distros has a 2 week max embargo period, but prefer 1 week). We can coordinate with Debian before then.

[Mate Kukri (mkukri)]

@exlerm EDK2 is mostly a developer kit, so there isn't much user documentation as such. Mainly there is this README for OVMF: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README. There also is a rather sparse GitHub wiki here: https://github.com/tianocore/tianocore.github.io/wiki/edk-ii.

[Mark Esler (eslerm)]

I have not been able to reach TianoCore developers, so I opened a discussion requesting they update their contact information.

https://github.com/tianocore/edk2/discussions/5224

[dann frazier (dannf)]

Thanks for pinging Mark - I see they've responded.

btw, I've updated the autopkgtests for edk2 to work in this mode. I can backport it to older series once we're ready to prepare those uploads.

[Mate Kukri (mkukri)]

I see their response the public post, but I haven't been added to the embargoed discussion page yet.

[Mark Esler (eslerm)]

Upstream set a new contact for Bugzilla access. They also added a group to the GHSA report. Feels like progress 🤞

[Mate Kukri (mkukri)]

This was reported upstream as bug #4641 on Tianocore's bugzilla. Note that unless you have an account there, you won't be able to access as it is classified as a private security bug.

[Mark Esler (eslerm)]

Tianocore is has begun publishing backlog security issues: https://github.com/tianocore/edk2/security/advisories

@mkukri, if you have all the information you need to release a patch, please choose a CRD date and mention it here and bugzilla.

[Mate Kukri (mkukri)]

@eslerm I think the EDK2 package is easy enough (despite SRU and such troubles), but I'd like the LXD folks to okay the patch too.

@tomparrott would someone from LXD be able to test this? (To that end I am attaching the "bare" patch for the edk2 tree to this comment). It should not need any other changes to edk2, nor your key enrollment setup as it only disables the Shell after SB was activated.

[Thomas Parrott (tomparrott)]

Hi @mkukri yes I have created to track this https://warthogs.atlassian.net/browse/LXD-800

[Mate Kukri (mkukri)]

Someone from intel responded to the edk2 bugzilla report, and they are proposing a patch for upstream that just removes the shell from builds when secure boot is enabled, which is probably a better solution but it breaks our current key enrollment, so my patch might be easier for backporting to stable series. Then we can eventually switch to something that doesnt need the shell.

If LXD is okay with the patch, could we make this public around end of February, then do SRUs and LXD updates after that?

[Thomas Parrott (tomparrott)]

@mkukri I've asked Aleks to take a look at this patch and try it in the next pulse. We'll let you know when we have results. Thanks

[Mate Kukri (mkukri)]

No rush, I am just trying to keep the ticket updated when I get something about this so it doesn't get forgotten.

[Aleksandr Mikhalitsyn (mihalicyn)]

Hi, Mate!

I have tested your patch with LXD and it works perfectly well.
I can see that when Secure Boot is enabled then the EFI Shell is not accessible,
but when Secure Boot is disabled then I can access the shell. As it follows
from the code this is intended behavior.

Thanks a lot for your work on that!

[Aleksandr Mikhalitsyn (mihalicyn)]

Do you think that we need to land this change into the LXD or we are still waiting when discussion with edk2 upstream folks will end?

[Mate Kukri (mkukri)]

Aleksandr,

Thank you very much for the testing, I appreciate it.

As far as upstream goes, they would like to go with the approach of compiling out the Shell fully from images that support Secure Boot. I ultimately think that is the best approach, and we should eventually do that too and use python-uefivars for key enrollment, but that is likely too big of a change for backporting to stable releases.

So unless there are objections, my current proposal is as follows:
1. Set the CRD for the CVE in Debian/Ubuntu, then after CRD release my patch as the security update on supported releases (applies to both edk2 package and LXD snap).
2. At some (currently unspecified) point in time, I'll develop a new key enrollment strategy for the edk2 package (that LXD can also choose to adopt), and then we can drop the patch from devel and compile out the Shell without having to do big changes to stable.

Mate

[Aleksandr Mikhalitsyn (mihalicyn)]

>1. Set the CRD for the CVE in Debian/Ubuntu, then after CRD release my patch as the security update on supported releases (applies to both edk2 package and LXD snap).

Sounds good. So, we are waiting for your ping to land this fix to the LXD then, right?

>2. At some (currently unspecified) point in time, I'll develop a new key enrollment strategy for the edk2 ...

Sure!

Alex

[Mate Kukri (mkukri)]

> Sounds good. So, we are waiting for your ping to land this fix to the LXD then, right?

Right, I think end of February is what was discussed here, but nothing is set in stone yet.

@eslerm What if we set Tuesday, 5 March 2024 as the CRD for this?

[Thomas Parrott (tomparrott)]

Will it be acceptable for land this fix in LXD sooner so we don't miss the Noble feature freeze?

[Mate Kukri (mkukri)]

I guess if everyone is comfortable with the patch, we should just set an earlier date and do it everywhere.

[Thomas Parrott (tomparrott)]

Thanks. I'd be hesitant to back port it to the 5.0 tree as this is a breaking feature change.

[Thomas Parrott (tomparrott)]

Which is why im keen to get it into the next LTS tree.

[Mark Esler (eslerm)]

Mate, is Tuesday, 5 March 2024 13:00 UTC+0 as the CRD okay? Ack to whatever hour you prefer and confirm.

Patch releases can coincide with this time. Thank you.

I've subscribed Salvatore Bonaccorso to make Debian Security aware of these issues.

[Thomas Parrott (tomparrott)]

Will we be able to land the patch in LXD in mid Feb to allow us to make the Noble feature freeze?

We don't have to make a big thing of it so as to avoid drawing attention, if that helps?

[Mate Kukri (mkukri)]

Unless someone else here needs more time, I think we should just move the CRD to 14th of February (or some other day around there).

This whole thing is not particularly high risk anyways (in my opinion), and will sit around unfixed for SRU verification in any case.

[Thomas Parrott (tomparrott)]

Sounds good to us.

[Thomas Parrott (tomparrott)]

BTW, what does CRD stand for?

[Mate Kukri (mkukri)]

@tomparrott Not 100% sure, but I assume it is short for "Coordinated Release Date".

[Mark Esler (eslerm)]

Yes, "Coordinated Release Date". Apologize for the jargon.

Let's lock in February 14th at 13:00 UTC+0.

[Mark Esler (eslerm)]

I discussed this with Multipass and added them to the bug.

Multipass believes they are unaffected as they use EDK2 from source with no special configurations.

Regardless, Multipass is meant for development and their Security Policy states that privilege escalation does not apply to their security scope: https://multipass.run/docs/about-security

[Mate Kukri (mkukri)]

@eslerm, the point is, it is the difficult configuration that is affected when building edk2. Unless they build with BuildShell=FALSE (or whatever it is called), they are affected.

Also do they mean the edk2 package, or edk2 from upstream? Because we are fixing the former, so that will get them the fix "for free". And upstream is changing the default configuration eventually to exclude the Shell from secure boot images.

But I guess if this is outside their security policy, it could be fixed whenever if at all.

[Mark Esler (eslerm)]

@mkukri, they are using edk2 from upstream. The Security Policy could be a little clearer, so I asked for clarification: https://discourse.ubuntu.com/t/about-security/32306/2?u=eslerm

[dann frazier (dannf)]

fyi, I've got tested packages for focal, jammy and mantic in the security PPA. These use @mkukri's shell disable patch.

For sid/noble, I've got the following queued up that actually disable the shell in the secboot variants. This required creating new flavors for AARCH64 and IA32 so that users can choose between secboot and shell-capable:

edk2 (2023.11-7) UNRELEASED; urgency=medium

  * ovmf, qemu-efi-*: Stop building Secure Boot code into non-secboot
    images so they can include a built-in shell which is unsafe in
    Secure Boot mode.
  * ovmf-ia32: Add non-secboot image. Thanks to Lionel Debroux.
    (Closes: #1023491).
  * debian/tests/shell.py: Add tests for ovmf-ia32 non-secboot image.
  * qemu-efi-aarch64: Add non-secboot variant. AAVMF_CODE.fd is the
    secboot variant, so name it AAVMF_CODE.no-secboot.fd.
  * qemu-efi-aarch64: Rename the secboot variant, AAVMF_CODE.fd,
    to AAVMF_CODE.secboot.fd and add a compat symlink.
  * ovmf, ovmf-ia32, qemu-efi-aarch64: Stop including a built-in shell
    in secboot variants, CVE-2023-48733. Thanks to Mate Kukri.
    LP: #2040137.
    - d/tests: Drop the boot-to-shell tests for images w/ Secure Boot.
    - d/tests: Update run_cmd_check_secure_boot() to not expect shell
      interaction.

 -- dann frazier <email address hidden> Sat, 10 Feb 2024 21:17:35 -0700

[Mate Kukri (mkukri)]

Approach sounds good to me, thanks for the work on this.

I am sure the builds are fine, but which PPA is this by the way?

Also I'll mail the same report sent to distros to oss-security at 1PM.

[Aleksandr Mikhalitsyn (mihalicyn)]

LXD snap:
https://github.com/canonical/lxd-pkg-snap/pull/329
https://github.com/canonical/lxd-pkg-snap/pull/330

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "0001-d-p-Disable-the-Shell-when-SecureBoot-is-enabled.pat.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2023.05-2ubuntu0.1

---------------
edk2 (2023.05-2ubuntu0.1) mantic; urgency=medium

  * Cherry-pick security fixes from upstream:
    - Fix heap buffer overflow in Tcg2MeasureGptTable(), CVE-2022-36763
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4117.patch
      + 0003-SecurityPkg-Adding-CVE-2022-36763-to-SecurityFixes.y.patch
    - Fix heap buffer overflow in Tcg2MeasurePeImage(), CVE-2022-36764
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411-2.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4118.patch
      + 0003-SecurityPkg-Adding-CVE-2022-36764-to-SecurityFixes.y.patch
    - Fix build failure due to symbol collision in above patches:
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411-3.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4117-2.patch
      + 0003-SecurityPkg-Updating-SecurityFixes.yaml-after-symbol.patch
    - Fix integer overflow in CreateHob(), CVE-2022-36765
      + 0001-UefiPayloadPkg-Hob-Integer-Overflow-in-CreateHob.patch
    - Fix a buffer overflow via a long server ID option in DHCPv6
      client, CVE-2023-45230:
      + 0001-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45230-Pa.patch
      + 0002-NetworkPkg-Add-Unit-tests-to-CI-and-create-Host-Test.patch
      + 0003-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45230-Un.patch
    - Fix an out-of-bounds read vulnerability when processing the IA_NA
      or IA_TA option in a DHCPv6 Advertise message, CVE-2023-45229:
      + 0004-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45229-Pa.patch
      + 0005-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45229-Un.patch
    - Fix an out-of-bounds read when processing Neighbor Discovery
      Redirect messages, CVE-2023-45231:
      + 0006-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45231-Patc.patch
      + 0007-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45231-Unit.patch
    - Avoid an infinite loop when parsing unknown options in the
      Destination Options header of IPv6, CVE-2023-45232:
      + 0008-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45232-Patc.patch
      + 0009-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45232-Unit.patch
    - Avoid an infinite loop when parsing a PadN option in the
      Destination Options header of IPv6, CVE-2023-45233:
      + 0010-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
      + 0011-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Fix a potential buffer overflow when processing a DNS Servers
      option from a DHCPv6 Advertise message, CVE-2023-45234:
      + 0013-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Fix a potential buffer overflow when handling a Server ID option
      from a DHCPv6 proxy Advertise message, CVE-2023-45235:
      + 0012-MdePkg-Test-Add-gRT_GetTime-Google-Test-Mock.patch
      + 0014-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Record fixes in a SecurityFix.yaml file:
      + 0015-NetworkPkg-Adds-a-SecurityFix.yaml-file.patch
  * Disable the built-in Shell when SecureBoot is enabled, CVE-2023-48733.
    Th...

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 0~20191122.bd85bf54-2ubuntu3.5

---------------
edk2 (0~20191122.bd85bf54-2ubuntu3.5) focal; urgency=medium

  * Disable the built-in Shell when SecureBoot is enabled, CVE-2023-48733.
    Thanks to Mate Kukri. LP: #2040137.
    - Backport support for GetSetupMode() and IsSecureBootEnabled():
      + 0001-SecurityPkg-Create-SecureBootVariableLib.patch
      + 0002-ArmVirtPkg-add-SecureBootVariableLib-class-resolutio.patch
      + 0003-OvmfPkg-add-SecureBootVariableLib-class-resolution.patch
      + 0004-SecurityPkg-SecureBootVariableLib-Added-newly-suppor.patch
      + 0005-EmulatorPkg-add-SecureBootVariableLib-class-resoluti.patch
    - Disable the built-in Shell when SecureBoot is enabled:
      + Disable-the-Shell-when-SecureBoot-is-enabled.patch

 -- dann frazier <email address hidden> Tue, 13 Feb 2024 17:52:30 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2022.02-3ubuntu0.22.04.2

---------------
edk2 (2022.02-3ubuntu0.22.04.2) jammy; urgency=medium

  * Cherry-pick security fixes from upstream:
    - Fix heap buffer overflow in Tcg2MeasureGptTable(), CVE-2022-36763
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4117.patch
      + 0003-SecurityPkg-Adding-CVE-2022-36763-to-SecurityFixes.y.patch
    - Fix heap buffer overflow in Tcg2MeasurePeImage(), CVE-2022-36764
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411-2.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4118.patch
      + 0003-SecurityPkg-Adding-CVE-2022-36764-to-SecurityFixes.y.patch
    - Fix build failure due to symbol collision in above patches:
      + 0001-SecurityPkg-DxeTpm2MeasureBootLib-SECURITY-PATCH-411-3.patch
      + 0002-SecurityPkg-DxeTpmMeasureBootLib-SECURITY-PATCH-4117-2.patch
      + 0003-SecurityPkg-Updating-SecurityFixes.yaml-after-symbol.patch
    - Fix integer overflow in CreateHob(), CVE-2022-36765
      + 0001-UefiPayloadPkg-Hob-Integer-Overflow-in-CreateHob.patch
    - Fix a buffer overflow via a long server ID option in DHCPv6
      client, CVE-2023-45230:
      + 0001-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45230-Pa.patch
      + 0002-NetworkPkg-Add-Unit-tests-to-CI-and-create-Host-Test.patch
      + 0003-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45230-Un.patch
    - Fix an out-of-bounds read vulnerability when processing the IA_NA
      or IA_TA option in a DHCPv6 Advertise message, CVE-2023-45229:
      + 0004-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45229-Pa.patch
      + 0005-NetworkPkg-Dhcp6Dxe-SECURITY-PATCH-CVE-2023-45229-Un.patch
    - Fix an out-of-bounds read when processing Neighbor Discovery
      Redirect messages, CVE-2023-45231:
      + 0006-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45231-Patc.patch
      + 0007-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45231-Unit.patch
    - Avoid an infinite loop when parsing unknown options in the
      Destination Options header of IPv6, CVE-2023-45232:
      + 0008-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45232-Patc.patch
      + 0009-NetworkPkg-Ip6Dxe-SECURITY-PATCH-CVE-2023-45232-Unit.patch
    - Avoid an infinite loop when parsing a PadN option in the
      Destination Options header of IPv6, CVE-2023-45233:
      + 0010-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
      + 0011-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Fix a potential buffer overflow when processing a DNS Servers
      option from a DHCPv6 Advertise message, CVE-2023-45234:
      + 0013-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Fix a potential buffer overflow when handling a Server ID option
      from a DHCPv6 proxy Advertise message, CVE-2023-45235:
      + 0014-NetworkPkg-UefiPxeBcDxe-SECURITY-PATCH-CVE-2023-4523.patch
    - Record fixes in a SecurityFix.yaml file:
      + 0015-NetworkPkg-Adds-a-SecurityFix.yaml-file.patch
  * Disable the built-in Shell when SecureBoot is enabled, CVE-2023-48733.
    Thanks to Mate Kukri. LP: #2040137.
    - Backport supp...

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2023.11-8

---------------
edk2 (2023.11-8) unstable; urgency=medium

  * debian/rules: Add debug flag to edk2-vars-generator.py commands.
  * debian/python/UEFI/Qemu: Fix var template for snakeoil commands.
  * debian/rules: Fix OVMF snakeoil enrollment by using the secboot
    CODE variant.
  * debian/tests/shell.py: Detect "Access Denied" message to fix
    test_*_ms_secure_boot_unsigned cases.
  * debian/rules: switch to 64bit PEI for OVMF(X64) images now that
    it supports S3 suspend. Thanks Hector Cao.

 -- dann frazier <email address hidden> Wed, 21 Feb 2024 16:25:20 -0700

[Mark Esler (eslerm)]

This has been addressed in the LXD snaps 5.21/stable (https://github.com/canonical/lxd-pkg-snap/commit/764ee08b) and 5.0/edge (https://github.com/canonical/lxd-pkg-snap/commit/bfe4270e).

All LXD software before version 4 are not affected.

Jammy, Mantic, and Noble do not have debs. Focal's deb is a snap installer. If LP is meant to track affected debs, all tagged LXD releases are invalid.