Re: [Patch 0/3] Add more checker for Tianocompress and Ueficompress

[Laszlo Ersek <lersek@redhat.com>]

On 10/18/18 15:36, Gao, Liming wrote:
> Laszlo and Star:
>   Thank your notes. I will add CVE number in patch subject although it
>   will make subject long than 80 characters.

I agree the subject will be overlong, but I also think that including
the CVE numbers is important enough for that.

> Here is my proposed patch subject: CVE-2017-5731..5735 MdePkg: Add
> more checker in UefiDecompressLib to access the valid buffer only.

I suggest (based on tradition) that we keep the normal subject at the
front, and then we append the CVE numbers at the end. Also, we should
spell out all those CVE identifiers individually, if the same patch
solves them all. It should be possible to search the subject line for
any one of these CVE numbers in separation, using the official CVE
number format.

>   In PEI phase, the recovery image is from the external device. If the
>   recovery image has the corrupt EFI compression section, they will be
>   handled by EFI Decompression PPI.

In the PEI phase, if the recovery image is crafted, it could cause a
buffer overflow during decompression. However, if the recovery image is
crafted, it might as well decompress cleanly, and once it is dispatched,
do "bad things". Do the decompression and the dispatch occur at
different privilege levels?

> In DXE phase, UEFI option ROM is the third party code. If it is EFI
> compression option ROM, EFI decompression protocol will be used to
> decode its data. I don't think SMM uses EFI decompression protocol.
> UefiDecompressionLib is used as EFI compression PPI/Protocol. It
> matches PI EFI compression section instead of GUID section. So, it has
> no GUID extraction PPI/Protocol.

In the DXE phase, if the option ROM is crafted, it could cause a buffer
overflow when it is decompressed. But, again, how is that different from
when a crafted oprom decompresses cleanly, and then does "bad things"
when it is dispatched?

Here (in the DXE phase), I can imagine two answers myself:

(1) Decompression occurs before Secure Boot validation, but dispatch
occurs only after. Therefore a crafted UEFI image could cause problems
via decompression even if it would fail SB verification later.

(2) Decompression of UEFI option ROMs occurs before PlatformBDS locks
down SMRAM and lockboxes. However, the execution of UEFI option ROMs
is deferred until after the lockdown.

Do these scenarios apply? Because, if they do, I agree the issue
qualifies as privilege escalation.

Thank you!
Laszlo