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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
