From nobody Sun Apr 28 08:01:17 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511874317661638.1158814147497; Tue, 28 Nov 2017 05:05:17 -0800 (PST) Received: from localhost ([::1]:37798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJfZU-0001oj-Vk for importer@patchew.org; Tue, 28 Nov 2017 08:05:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJfXt-00015O-SF for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:03:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJfXr-0003ez-SC for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:03:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41522) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJfXi-0003cU-7Y; Tue, 28 Nov 2017 08:03:18 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3C0C8C070145; Tue, 28 Nov 2017 13:03:17 +0000 (UTC) Received: from red.redhat.com (ovpn-122-79.rdu2.redhat.com [10.10.122.79]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4ACEC60484; Tue, 28 Nov 2017 13:03:06 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 28 Nov 2017 07:02:47 -0600 Message-Id: <20171128130248.901-2-eblake@redhat.com> In-Reply-To: <20171128130248.901-1-eblake@redhat.com> References: <20171128130248.901-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 28 Nov 2017 13:03:17 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/2] nbd/server: CVE-2017-15119 Reject options larger than 32M X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, vsementsov@virtuozzo.com, "open list:Network Block Dev..." , secalert@redhat.com, qemu-stable@nongnu.org, ppandit@redhat.com, Paolo Bonzini Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The NBD spec gives us permission to abruptly disconnect on clients that send outrageously large option requests, rather than having to spend the time reading to the end of the option. No real option request requires that much data anyways; and meanwhile, we already have the practice of abruptly dropping the connection on any client that sends NBD_CMD_WRITE with a payload larger than 32M. For comparison, nbdkit drops the connection on any request with more than 4096 bytes; however, that limit is probably too low (as the NBD spec states an export name can theoretically be up to 4096 bytes, which means a valid NBD_OPT_INFO could be even longer) - even if qemu doesn't permit exports longer than 256 bytes. It could be argued that a malicious client trying to get us to read nearly 4G of data on a bad request is a form of denial of service. In particular, if the server requires TLS, but a client that does not know the TLS credentials sends any option (other than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated payload of nearly 4G, then the server was keeping the connection alive trying to read all the payload, tying up resources that it would rather be spending on a client that can get past the TLS handshake. Hence, this warranted a CVE. Present since at least 2.5 when handling known options, and made worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE to handle unknown options. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake --- nbd/server.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/nbd/server.c b/nbd/server.c index 7d6801b427..a81801e3bc 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -673,6 +673,12 @@ static int nbd_negotiate_options(NBDClient *client, ui= nt16_t myflags, } length =3D be32_to_cpu(length); + if (length > NBD_MAX_BUFFER_SIZE) { + error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u= )", + length, NBD_MAX_BUFFER_SIZE); + return -EINVAL; + } + trace_nbd_negotiate_options_check_option(option, nbd_opt_lookup(option)); if (client->tlscreds && --=20 2.14.3 From nobody Sun Apr 28 08:01:17 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511874412245529.1310021545354; Tue, 28 Nov 2017 05:06:52 -0800 (PST) Received: from localhost ([::1]:37848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJfas-0002ve-Vd for importer@patchew.org; Tue, 28 Nov 2017 08:06:35 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJfY8-0001D4-Cu for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:03:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJfY2-0003hx-Hk for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:03:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35262) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJfXq-0003eX-Jg; Tue, 28 Nov 2017 08:03:26 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4829127AE; Tue, 28 Nov 2017 13:03:25 +0000 (UTC) Received: from red.redhat.com (ovpn-122-79.rdu2.redhat.com [10.10.122.79]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7BF5F605D8; Tue, 28 Nov 2017 13:03:17 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 28 Nov 2017 07:02:48 -0600 Message-Id: <20171128130248.901-3-eblake@redhat.com> In-Reply-To: <20171128130248.901-1-eblake@redhat.com> References: <20171128130248.901-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 28 Nov 2017 13:03:25 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 2/2] nbd/server: CVE-2017-15118 Stack smash on large export name X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, vsementsov@virtuozzo.com, "open list:Network Block Dev..." , secalert@redhat.com, qemu-stable@nongnu.org, ppandit@redhat.com, Paolo Bonzini Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Introduced in commit f37708f6b8 (2.10). The NBD spec says a client can request export names up to 4096 bytes in length, even though they should not expect success on names longer than 256. However, qemu hard-codes the limit of 256, and fails to filter out a client that probes for a longer name; the result is a stack smash that can potentially give an attacker arbitrary control over the qemu process. The smash can be easily demonstrated with this client: $ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a) If the qemu NBD server binary (whether the standalone qemu-nbd, or the builtin server of QMP nbd-server-start) was compiled with -fstack-protector-strong, the ability to exploit the stack smash into arbitrary execution is a lot more difficult (but still theoretically possible to a determined attacker, perhaps in combination with other CVEs). Still, crashing a running qemu (and losing the VM) is bad enough, even if the attacker did not obtain full execution control. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake --- nbd/server.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nbd/server.c b/nbd/server.c index a81801e3bc..92c0fdd03b 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -386,6 +386,10 @@ static int nbd_negotiate_handle_info(NBDClient *client= , uint32_t length, msg =3D "name length is incorrect"; goto invalid; } + if (namelen >=3D sizeof(name)) { + msg =3D "name too long for qemu"; + goto invalid; + } if (nbd_read(client->ioc, name, namelen, errp) < 0) { return -EIO; } --=20 2.14.3