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

["Gao, Liming" <liming.gao@intel.com>]

Laszlo and Star:
  Thank your notes. I will add CVE number in patch subject although it will make subject long than 80 characters. Here is my proposed patch subject: CVE-2017-5731..5735 MdePkg: Add more checker in UefiDecompressLib to access the valid buffer only. 

  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 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. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Thursday, October 18, 2018 9:03 PM
> To: Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2] [Patch 0/3] Add more checker for Tianocompress and Ueficompress
> 
> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel