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

[Laszlo Ersek <lersek@redhat.com>]

On 10/18/18 05:04, Zeng, Star wrote:
> On 2018/10/16 10:06, Liming Gao wrote:
>> https://bugzilla.tianocore.org/show_bug.cgi?id=686
>>
>> Liming Gao (3):
>>    MdePkg: Add more checker in UefiDecompressLib to access the valid
>>      buffer only
>>    IntelFrameworkModulePkg: Add more checker in UefiTianoDecompressLib
>>    BaseTools: Add more checker in Decompress algorithm to access the
>>      valid buffer
> 
> Hi Liming,
> 
> If these patches are not pushed yet, I am glad to broadcast the good
> request "add CVE number in subject line" from Laszlo at
> https://lists.01.org/pipermail/edk2-devel/2018-October/031031.html. :)

Indeed; I now see on the BZ that no fewer than five CVEs are associated
with this series / BZ. Thank you Star for pointing that out.

Can we get a more detailed attack / threat analysis on the BZ, please?
Comment 7 says, "Impact: Elevation of Privilege". What does that mean
precisely?

For example, I'd like to evaluate the practical impact on ArmVirtQemu
and OVMF. From the build reports, those platforms use the
UefiDecompressLib class in "DxeIpl.inf" and "DxeMain.inf" only.

In turn, the DXE IPL PEIM seems to expose the UEFI decompress facility
via EFI_PEI_DECOMPRESS_PPI, and the DXE core does the same via
EFI_DECOMPRESS_PROTOCOL.

I don't think 3rd party drivers / applications / OS-es have access to
the PEI phase, so I think a buffer overflow in EFI_PEI_DECOMPRESS_PPI
might be exploitable. (Or is perhaps EFI_PEI_DECOMPRESS_PPI used for
update capsule processing on some platforms?)

Regarding EFI_DECOMPRESS_PROTOCOL; any 3rd party UEFI driver or app can
locate and call it. But how can the protocol's vulnerability exploited
for "Elevation of Privilege"? Can it be used to attack SMM somehow? I
don't see any SMM module in the edk2 tree consuming
"gEfiDecompressProtocolGuid".

Is UefiDecompressLib perhaps used for extracting GUID-ed sections as
well (on some other platforms)?

Thanks
Laszlo