From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C8E7D2194D387 for ; Thu, 18 Oct 2018 06:02:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4395188E56; Thu, 18 Oct 2018 13:02:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-50.rdu2.redhat.com [10.10.121.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8730D177F7; Thu, 18 Oct 2018 13:02:41 +0000 (UTC) To: "Zeng, Star" , Liming Gao , edk2-devel@lists.01.org, Ard Biesheuvel , "Gao, Liming" References: <1539655573-5456-1-git-send-email-liming.gao@intel.com> From: Laszlo Ersek Message-ID: Date: Thu, 18 Oct 2018 15:02:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 18 Oct 2018 13:02:44 +0000 (UTC) Subject: Re: [Patch 0/3] Add more checker for Tianocompress and Ueficompress X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 13:02:45 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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