From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.1648.1578527006931151424 for ; Wed, 08 Jan 2020 15:43:27 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=N755S0eO; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578527005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+paklwiEblagYjChyUoB72yvyGJ/Kux8/j1gNmKXwJs=; b=N755S0eOhSMllARyyNPxuoIfm/VK4JgvTXuFwuzUB2dxzmRrC3UGqGQYkwZu1okRNL18rN bOaPUqpuT9HnF0DuvMYKSkuXHe5a0tnFugyvKNLDeEBCb3e1DBaIMv+M21/n0kdhr/5KjC kWHIzV0hJIA3iiaJvRLTzJnEYFf6gh8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-430-ux_dN25ONq-_H9bGXbxvWg-1; Wed, 08 Jan 2020 18:43:21 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C504E10054E3; Wed, 8 Jan 2020 23:43:20 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-37.ams2.redhat.com [10.36.117.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id A8F2A10027A6; Wed, 8 Jan 2020 23:43:19 +0000 (UTC) From: "Laszlo Ersek" To: edk2-devel-groups-io Cc: Jiaxin Wu , Maciej Rabeda , Siyuan Fu Subject: [PATCH 2/2] NetworkPkg/HttpDxe: fix 32-bit truncation in HTTPS download Date: Thu, 9 Jan 2020 00:43:13 +0100 Message-Id: <20200108234313.28510-3-lersek@redhat.com> In-Reply-To: <20200108234313.28510-1-lersek@redhat.com> References: <20200108234313.28510-1-lersek@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: ux_dN25ONq-_H9bGXbxvWg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable When downloading over TLS, each TLS message ("APP packet") is returned as a (decrypted) fragment table by EFI_TLS_PROTOCOL.ProcessPacket(). The TlsProcessMessage() function in "NetworkPkg/HttpDxe/HttpsSupport.c" linearizes the fragment table into a single contiguous data block. The resultant flat data block contains both TLS headers and data. The HttpsReceive() function parses the actual application data -- in this case: decrypted HTTP data -- out of the flattened TLS data block, peeling off the TLS headers. The HttpResponseWorker() function in "NetworkPkg/HttpDxe/HttpImpl.c" propagates this HTTP data outwards, implementing the EFI_HTTP_PROTOCOL.Response() function. Now consider the following documentation for EFI_HTTP_PROTOCOL.Response(), quoted from "MdePkg/Include/Protocol/Http.h": > It is the responsibility of the caller to allocate a buffer for Body and > specify the size in BodyLength. If the remote host provides a response > that contains a content body, up to BodyLength bytes will be copied from > the receive buffer into Body and BodyLength will be updated with the > amount of bytes received and copied to Body. This allows the client to > download a large file in chunks instead of into one contiguous block of > memory. Note that, if the caller-allocated buffer is larger than the server-provided chunk, then the transfer length is limited by the latter. This is in fact the dominant case when downloading a huge file (for which UefiBootManagerLib allocated a huge contiguous RAM Disk buffer) in small TLS messages. For adjusting BodyLength as described above -- i.e., to the application data chunk that has been extracted from the TLS message --, the HttpResponseWorker() function employs the following assignment: HttpMsg->BodyLength =3D MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength= ); The (UINT32) cast is motivated by the MIN() requirement -- in "MdePkg/Include/Base.h" -- that both arguments be of the same type. "Fragment.Len" (NET_FRAGMENT.Len) has type UINT32, and "HttpMsg->BodyLength" (EFI_HTTP_MESSAGE.BodyLength) has type UINTN. Therefore a cast is indeed necessary. Unfortunately, the cast is done in the wrong direction. Consider the following circumstances: - "Fragment.Len" happens to be consistently 16KiB, dictated by the HTTPS Server's TLS stack, - the size of the file to download is 4GiB + N*16KiB, where N is a positive integer. As the download progresses, each received 16KiB application data chunk brings the *next* input value of BodyLength closer down to 4GiB. The cast in MIN() always masks off the high-order bits from the input value of BodyLength, but this is no problem because the low-order bits are nonzero, therefore the MIN() always permits progress. However, once BodyLength reaches 4GiB exactly on input, the MIN() invocation produces a zero value. HttpResponseWorker() adjusts the output value of BodyLength to zero, and then passes it to HttpParseMessageBody(). HttpParseMessageBody() (in "NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c") rejects the zero BodyLength with EFI_INVALID_PARAMETER, which is fully propagated outwards, and aborts the HTTPS download. HttpBootDxe writes the message "Error: Unexpected network error" to the UEFI console. For example, a file with size (4GiB + 197MiB) terminates after downloading just 197MiB. Invert the direction of the cast: widen "Fragment.Len" to UINTN. Cc: Jiaxin Wu Cc: Maciej Rabeda Cc: Siyuan Fu Signed-off-by: Laszlo Ersek --- NetworkPkg/HttpDxe/HttpImpl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c index 6b877314bd57..1acbb60d1014 100644 --- a/NetworkPkg/HttpDxe/HttpImpl.c +++ b/NetworkPkg/HttpDxe/HttpImpl.c @@ -1348,7 +1348,7 @@ HttpResponseWorker ( // // Process the received the body packet. // - HttpMsg->BodyLength =3D MIN (Fragment.Len, (UINT32) HttpMsg->BodyLengt= h); + HttpMsg->BodyLength =3D MIN ((UINTN) Fragment.Len, HttpMsg->BodyLength= ); =20 CopyMem (HttpMsg->Body, Fragment.Bulk, HttpMsg->BodyLength); =20 --=20 2.19.1.3.g30247aa5d201