[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Feb 2024 15:47:23 +0000
From: Mate Kukri <mate.kukri@...onical.com>
To: corsac@...ian.org, oss-security@...ts.openwall.com
Subject: Re: Secure Boot bypass in EDK2 based Virtual Machine firmware
That is correct in the general case, but here the issue comes from the
fact that a copy of the Shell was included in the firmware image
itself, and as a built-in application was implicitly trusted.
On Wed, Feb 14, 2024 at 3:44 PM Yves-Alexis Perez <corsac@...ian.org> wrote:
>
> On Wed, Feb 14, 2024 at 02:40:43PM +0000, Mate Kukri wrote:
> > 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.
>
> Hi Mate,
>
> I'm not sure if I understand everything correctly, but if UEFI Secure
> Boot is enabled, shouldn't the shell.efi binary need to be explicitely
> signed in order for it to be correctly loaded? It doesnt look like a
> good idea to sign shell.efi on a production platform, but for test
> purposes it might be relevant.
>
> Regards,
> --
> Yves-Alexis Perez
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
