|
 |
4a2fec |
From 0ce164b7410c1c4a75eefaef48896ee245eeba5c Mon Sep 17 00:00:00 2001
|
|
|
4a2fec |
From: Eric Blake <eblake@redhat.com>
|
|
|
4a2fec |
Date: Wed, 13 Dec 2017 18:17:29 +0100
|
|
|
4a2fec |
Subject: [PATCH 4/6] nbd/server: CVE-2017-15119 Reject options larger than 32M
|
|
|
4a2fec |
|
|
|
4a2fec |
RH-Author: Eric Blake <eblake@redhat.com>
|
|
|
4a2fec |
Message-id: <20171213181730.1278-2-eblake@redhat.com>
|
|
|
4a2fec |
Patchwork-id: 78394
|
|
|
4a2fec |
O-Subject: [RHEV-7.5 qemu-kvm-rhev PATCH 1/2] nbd/server: CVE-2017-15119 Reject options larger than 32M
|
|
|
4a2fec |
Bugzilla: 1518529 1518551
|
|
|
4a2fec |
CVE: CVE-2017-15119/20171128
|
|
|
4a2fec |
RH-Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
|
|
|
4a2fec |
RH-Acked-by: John Snow <jsnow@redhat.com>
|
|
|
4a2fec |
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
|
4a2fec |
|
|
|
4a2fec |
The NBD spec gives us permission to abruptly disconnect on clients
|
|
|
4a2fec |
that send outrageously large option requests, rather than having
|
|
|
4a2fec |
to spend the time reading to the end of the option. No real
|
|
|
4a2fec |
option request requires that much data anyways; and meanwhile, we
|
|
|
4a2fec |
already have the practice of abruptly dropping the connection on
|
|
|
4a2fec |
any client that sends NBD_CMD_WRITE with a payload larger than 32M.
|
|
|
4a2fec |
|
|
|
4a2fec |
For comparison, nbdkit drops the connection on any request with
|
|
|
4a2fec |
more than 4096 bytes; however, that limit is probably too low
|
|
|
4a2fec |
(as the NBD spec states an export name can theoretically be up
|
|
|
4a2fec |
to 4096 bytes, which means a valid NBD_OPT_INFO could be even
|
|
|
4a2fec |
longer) - even if qemu doesn't permit exports longer than 256
|
|
|
4a2fec |
bytes.
|
|
|
4a2fec |
|
|
|
4a2fec |
It could be argued that a malicious client trying to get us to
|
|
|
4a2fec |
read nearly 4G of data on a bad request is a form of denial of
|
|
|
4a2fec |
service. In particular, if the server requires TLS, but a client
|
|
|
4a2fec |
that does not know the TLS credentials sends any option (other
|
|
|
4a2fec |
than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
|
|
|
4a2fec |
payload of nearly 4G, then the server was keeping the connection
|
|
|
4a2fec |
alive trying to read all the payload, tying up resources that it
|
|
|
4a2fec |
would rather be spending on a client that can get past the TLS
|
|
|
4a2fec |
handshake. Hence, this warranted a CVE.
|
|
|
4a2fec |
|
|
|
4a2fec |
Present since at least 2.5 when handling known options, and made
|
|
|
4a2fec |
worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
|
|
|
4a2fec |
to handle unknown options.
|
|
|
4a2fec |
|
|
|
4a2fec |
CC: qemu-stable@nongnu.org
|
|
|
4a2fec |
Signed-off-by: Eric Blake <eblake@redhat.com>
|
|
|
4a2fec |
(cherry picked from commit fdad35ef6c5839d50dfc14073364ac893afebc30)
|
|
|
4a2fec |
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
|
|
|
4a2fec |
---
|
|
|
4a2fec |
nbd/server.c | 6 ++++++
|
|
|
4a2fec |
1 file changed, 6 insertions(+)
|
|
|
4a2fec |
|
|
|
4a2fec |
diff --git a/nbd/server.c b/nbd/server.c
|
|
|
4a2fec |
index 993ade3..b93cb88 100644
|
|
|
4a2fec |
--- a/nbd/server.c
|
|
|
4a2fec |
+++ b/nbd/server.c
|
|
|
4a2fec |
@@ -661,6 +661,12 @@ static int nbd_negotiate_options(NBDClient *client, uint16_t myflags,
|
|
|
4a2fec |
}
|
|
|
4a2fec |
length = be32_to_cpu(length);
|
|
|
4a2fec |
|
|
|
4a2fec |
+ if (length > NBD_MAX_BUFFER_SIZE) {
|
|
|
4a2fec |
+ error_setg(errp, "len (%" PRIu32" ) is larger than max len (%u)",
|
|
|
4a2fec |
+ length, NBD_MAX_BUFFER_SIZE);
|
|
|
4a2fec |
+ return -EINVAL;
|
|
|
4a2fec |
+ }
|
|
|
4a2fec |
+
|
|
|
4a2fec |
trace_nbd_negotiate_options_check_option(option,
|
|
|
4a2fec |
nbd_opt_lookup(option));
|
|
|
4a2fec |
if (client->tlscreds &&
|
|
|
4a2fec |
--
|
|
|
4a2fec |
1.8.3.1
|
|
|
4a2fec |
|