From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.100; helo=mga07.intel.com; envelope-from=qin.long@intel.com; receiver=edk2-devel@lists.01.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 7D3AA2034A7B8 for ; Wed, 1 Nov 2017 00:56:04 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP; 01 Nov 2017 00:59:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,327,1505804400"; d="scan'208";a="1031986009" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 01 Nov 2017 00:59:56 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Nov 2017 00:59:56 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.152]) with mapi id 14.03.0319.002; Wed, 1 Nov 2017 15:59:54 +0800 From: "Long, Qin" To: "Wang, Jian J" , "edk2-devel@lists.01.org" CC: "Ye, Ting" , "lersek@redhat.com" Thread-Topic: [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in realloc wrapper Thread-Index: AQHTUuL2KgBm/9Q/DE+WagMzGNeXFqL/JceQ Date: Wed, 1 Nov 2017 07:59:54 +0000 Message-ID: References: <20171031083930.12800-1-qin.long@intel.com> <20171031083930.12800-2-qin.long@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in realloc wrapper X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 07:56:04 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Jian. It's great to pass the validation.=20 And exactly, the null data checking was missed. I will re-produce the V2 pa= tch.=20 Best Regards & Thanks, LONG, Qin -----Original Message----- From: Wang, Jian J=20 Sent: Wednesday, November 1, 2017 3:28 PM To: Long, Qin ; edk2-devel@lists.01.org Cc: Ye, Ting ; lersek@redhat.com Subject: RE: [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue = in realloc wrapper Hi Qin, Thanks for fixing this issue. Please find my comments below. Besides that, the patch has been passed the boot validation. Validated-by: Jian J Wang Thanks, Jian > -----Original Message----- > From: Long, Qin > Sent: Tuesday, October 31, 2017 4:39 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; lersek@redhat.com; Wang, Jian J=20 > ; Long, Qin > Subject: [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue=20 > in realloc wrapper >=20 > There is one long-standing problem in CRT realloc wrapper, which will=20 > cause the obvious buffer overflow issue when re-allocating one bigger=20 > memory block: > void *realloc (void *ptr, size_t size) > { > // > // BUG: hardcode OldSize =3D=3D size! We have no any knowledge abou= t > // memory size of original pointer ptr. > // > return ReallocatePool ((UINTN) size, (UINTN) size, ptr); > } > This patch introduces one extra header to record the memory buffer=20 > size information when allocating memory block from malloc routine, and=20 > re-wrap the realloc() and free() routines to remove this BUG. >=20 > Cc: Laszlo Ersek > Cc: Ting Ye > Cc: Jian J Wang > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Qin Long > --- > .../BaseCryptLib/SysCall/BaseMemAllocation.c | 72 ++++++++++++++++= +++- > -- > 1 file changed, 65 insertions(+), 7 deletions(-) >=20 > diff --git=20 > a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c > index f390e0d449..ed37a0ff39 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c > @@ -16,6 +16,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,=20 > EITHER EXPRESS OR IMPLIED. > #include > #include >=20 > +// > +// Extra header to record the memory buffer size from malloc routine. > +// > +#define CRYPTMEM_HEAD_SIGNATURE SIGNATURE_32('c','m','h','d') > +typedef struct { > + UINT32 Signature; > + UINT32 Reserved; > + UINTN Size; > +} CRYPTMEM_HEAD; > + > +#define CRYPTMEM_OVERHEAD sizeof(CRYPTMEM_HEAD) Any consideration of the "Reserved" field, Padding? Alignment? Future exten= dibility? [Long, Qin] There is no special consideration on this field.=20 Just keep this style as other POOL_HEAD usage, and may be for possible fut= ure extension.=20 > + > // > // -- Memory-Allocation Routines -- > // > @@ -23,27 +35,73 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,=20 > EITHER EXPRESS OR IMPLIED. > /* Allocates memory blocks */ > void *malloc (size_t size) > { > - return AllocatePool ((UINTN) size); > + CRYPTMEM_HEAD *PoolHdr; > + UINTN NewSize; > + VOID *Data; > + > + // > + // Adjust the size by the buffer header overhead // NewSize =3D=20 > + (UINTN)(size) + CRYPTMEM_OVERHEAD; > + > + Data =3D AllocatePool (NewSize); > + if (Data !=3D NULL) { > + PoolHdr =3D (CRYPTMEM_HEAD *)Data; > + // > + // Record the memory brief information > + // > + PoolHdr->Signature =3D CRYPTMEM_HEAD_SIGNATURE; > + PoolHdr->Size =3D size; > + } > + return (VOID *)(PoolHdr + 1); > } >=20 Although it's very rare, the logic of code above doesn't consider case of D= ata =3D=3D NULL. And above code might not pass GCC build because there's a chance that PoolH= dr is not initialized. [Long, Qin] Agree. > /* Reallocate memory blocks */ > void *realloc (void *ptr, size_t size) { > - // > - // BUG: hardcode OldSize =3D=3D size! We have no any knowledge about > - // memory size of original pointer ptr. > - // > - return ReallocatePool ((UINTN) size, (UINTN) size, ptr); > + CRYPTMEM_HEAD *OldPoolHdr; > + CRYPTMEM_HEAD *NewPoolHdr; > + UINTN OldSize; > + UINTN NewSize; > + VOID *Data; > + > + NewSize =3D (UINTN)size + CRYPTMEM_OVERHEAD; Data =3D AllocatePool=20 > + (NewSize); if (Data !=3D NULL) { > + NewPoolHdr =3D (CRYPTMEM_HEAD *)Data; > + NewPoolHdr->Signature =3D CRYPTMEM_HEAD_SIGNATURE; > + NewPoolHdr->Size =3D size; > + if (ptr !=3D NULL) { > + // > + // Retrieve the original size from the buffer header. > + // > + OldPoolHdr =3D (CRYPTMEM_HEAD *)ptr - 1; > + ASSERT (OldPoolHdr->Signature =3D=3D CRYPTMEM_HEAD_SIGNATURE); > + OldSize =3D OldPoolHdr->Size; > + > + // > + // Duplicate the buffer content. > + // > + CopyMem ((VOID *)(NewPoolHdr + 1), ptr, MIN (OldSize, size)); > + FreePool ((VOID *)OldPoolHdr); > + } > + } > + > + return (VOID *)(NewPoolHdr + 1); > } >=20 1. The same as above, the code logic doesn't consider the case of Data =3D= =3D NULL. 2. ptr should be better checked against NULL before allocating new pool [Long, Qin] 1. Agree 2. Looks it's not necessary. The logic is same as our ReallocatePool(). > /* De-allocates or frees a memory block */ void free (void *ptr) { > + CRYPTMEM_HEAD *PoolHdr; > + > // > // In Standard C, free() handles a null pointer argument transparently= . This > // is not true of FreePool() below, so protect it. > // > if (ptr !=3D NULL) { > - FreePool (ptr); > + PoolHdr =3D (CRYPTMEM_HEAD *)ptr - 1; > + ASSERT (PoolHdr->Signature =3D=3D CRYPTMEM_HEAD_SIGNATURE); > + FreePool (PoolHdr); > } > } > -- > 2.14.1.windows.1