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 BD7222194D387 for ; Thu, 18 Oct 2018 09:01:22 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B1501C04C27D; Thu, 18 Oct 2018 16:01:21 +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 A3ECC5B687; Thu, 18 Oct 2018 16:01:20 +0000 (UTC) To: "Gao, Liming" , "Zeng, Star" , "edk2-devel@lists.01.org" , Ard Biesheuvel References: <1539655573-5456-1-git-send-email-liming.gao@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E33D7CF@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <155ff850-d652-30c9-5c02-7f1412a8f079@redhat.com> Date: Thu, 18 Oct 2018 18:01:14 +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: <4A89E2EF3DFEDB4C8BFDE51014F606A14E33D7CF@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 18 Oct 2018 16:01:21 +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 16:01:23 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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