| Message ID | 20240806022542.381883-5-eblake@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | NBD CVE-2024-7409 | expand |
On Mon, Aug 05, 2024 at 09:21:35PM -0500, Eric Blake wrote: > A malicious client can attempt to connect to an NBD server, and then > intentionally delay progress in the handshake, including if it does > not know the TLS secrets. Although this behavior can be bounded by > the max-connections parameter, the QMP nbd-server-start currently > defaults to unlimited incoming client connections. Worse, if the > client waits to close the socket until after the QMP nbd-server-stop > command is executed, qemu will then SEGV when trying to dereference > the NULL nbd_server global whish is no longer present, which amounts > to a denial of service attack. If another NBD server is started > before the malicious client disconnects, I cannot rule out additional > adverse effects when the old client interferes with the connection > count of the new server. > > For environments without this patch, the CVE can be mitigated by > ensuring (such as via a firewall) that only trusted clients can > connect to an NBD server. Note that using frameworks like libvirt > that ensure that TLS is used and that nbd-server-stop is not executed > while any trusted clients are still connected will only help if there > is also no possibility for an untrusted client to open a connection > but then stall on the NBD handshake. > > This patch fixes the problem by tracking all client sockets opened > while the server is running, and forcefully closing any such sockets > remaining without a completed handshake at the time of > nbd-server-stop, then waiting until the coroutines servicing those > sockets notice the state change. nbd-server-stop may now take > slightly longer to execute, but the extra time is independent of > client response behaviors, and is generally no worse than the time > already taken by the blk_exp_close_all_type() that disconnects all > clients that completed handshakes (since that code also has an > AIO_WAIT_WHILE_UNLOCKED). For a long-running server with lots of > clients rapidly connecting and disconnecting, the memory used to track > all client sockets can result in some memory overhead, but it is not a > leak; the next patch will further optimize that by cleaning up memory > as clients go away. At any rate, this patch in isolation is > sufficient to fix the CVE. > > This patch relies heavily on the fact that nbd/server.c guarantees > that it only calls nbd_blockdev_client_closed() from the main loop > (see the assertion in nbd_client_put() and the hoops used in > nbd_client_put_nonzero() to achieve that); if we did not have that > guarantee, we would also need a mutex protecting our accesses of the > list of connections to survive re-entrancy from independent iothreads. > > Although I did not actually try to test old builds, it looks like this > problem has existed since at least commit 862172f45c (v2.12.0, 2017) - > even back in that patch to start using a QIONetListener to handle > listening on multiple sockets, nbd_server_free() was already unaware > that the nbd_blockdev_client_closed callback can be reached later by a > client thread that has not completed handshakes (and therefore the > client's socket never got added to the list closed in > nbd_export_close_all), despite that patch intentionally tearing down > the QIONetListener to prevent new clients. > > Reported-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com> > Fixes: CVE-2024-7409 > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > blockdev-nbd.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> With regards, Daniel
diff --git a/blockdev-nbd.c b/blockdev-nbd.c index 213012435f4..b8f00f402c6 100644 --- a/blockdev-nbd.c +++ b/blockdev-nbd.c @@ -21,12 +21,18 @@ #include "io/channel-socket.h" #include "io/net-listener.h" +typedef struct NBDConn { + QIOChannelSocket *cioc; + QSLIST_ENTRY(NBDConn) next; +} NBDConn; + typedef struct NBDServerData { QIONetListener *listener; QCryptoTLSCreds *tlscreds; char *tlsauthz; uint32_t max_connections; uint32_t connections; + QSLIST_HEAD(, NBDConn) conns; } NBDServerData; static NBDServerData *nbd_server; @@ -51,6 +57,8 @@ int nbd_server_max_connections(void) static void nbd_blockdev_client_closed(NBDClient *client, bool ignored) { + assert(qemu_in_main_thread() && nbd_server); + nbd_client_put(client); assert(nbd_server->connections > 0); nbd_server->connections--; @@ -60,7 +68,13 @@ static void nbd_blockdev_client_closed(NBDClient *client, bool ignored) static void nbd_accept(QIONetListener *listener, QIOChannelSocket *cioc, gpointer opaque) { + NBDConn *conn = g_new0(NBDConn, 1); + + assert(qemu_in_main_thread() && nbd_server); nbd_server->connections++; + object_ref(OBJECT(cioc)); + conn->cioc = cioc; + QSLIST_INSERT_HEAD(&nbd_server->conns, conn, next); nbd_update_server_watch(nbd_server); qio_channel_set_name(QIO_CHANNEL(cioc), "nbd-server"); @@ -83,8 +97,24 @@ static void nbd_server_free(NBDServerData *server) return; } + /* + * Forcefully close the listener socket, and any clients that have + * not yet disconnected on their own. + */ qio_net_listener_disconnect(server->listener); object_unref(OBJECT(server->listener)); + while (!QSLIST_EMPTY(&server->conns)) { + NBDConn *conn = QSLIST_FIRST(&server->conns); + + qio_channel_shutdown(QIO_CHANNEL(conn->cioc), QIO_CHANNEL_SHUTDOWN_BOTH, + NULL); + object_unref(OBJECT(conn->cioc)); + QSLIST_REMOVE_HEAD(&server->conns, next); + g_free(conn); + } + + AIO_WAIT_WHILE_UNLOCKED(NULL, server->connections > 0); + if (server->tlscreds) { object_unref(OBJECT(server->tlscreds)); }
A malicious client can attempt to connect to an NBD server, and then intentionally delay progress in the handshake, including if it does not know the TLS secrets. Although this behavior can be bounded by the max-connections parameter, the QMP nbd-server-start currently defaults to unlimited incoming client connections. Worse, if the client waits to close the socket until after the QMP nbd-server-stop command is executed, qemu will then SEGV when trying to dereference the NULL nbd_server global whish is no longer present, which amounts to a denial of service attack. If another NBD server is started before the malicious client disconnects, I cannot rule out additional adverse effects when the old client interferes with the connection count of the new server. For environments without this patch, the CVE can be mitigated by ensuring (such as via a firewall) that only trusted clients can connect to an NBD server. Note that using frameworks like libvirt that ensure that TLS is used and that nbd-server-stop is not executed while any trusted clients are still connected will only help if there is also no possibility for an untrusted client to open a connection but then stall on the NBD handshake. This patch fixes the problem by tracking all client sockets opened while the server is running, and forcefully closing any such sockets remaining without a completed handshake at the time of nbd-server-stop, then waiting until the coroutines servicing those sockets notice the state change. nbd-server-stop may now take slightly longer to execute, but the extra time is independent of client response behaviors, and is generally no worse than the time already taken by the blk_exp_close_all_type() that disconnects all clients that completed handshakes (since that code also has an AIO_WAIT_WHILE_UNLOCKED). For a long-running server with lots of clients rapidly connecting and disconnecting, the memory used to track all client sockets can result in some memory overhead, but it is not a leak; the next patch will further optimize that by cleaning up memory as clients go away. At any rate, this patch in isolation is sufficient to fix the CVE. This patch relies heavily on the fact that nbd/server.c guarantees that it only calls nbd_blockdev_client_closed() from the main loop (see the assertion in nbd_client_put() and the hoops used in nbd_client_put_nonzero() to achieve that); if we did not have that guarantee, we would also need a mutex protecting our accesses of the list of connections to survive re-entrancy from independent iothreads. Although I did not actually try to test old builds, it looks like this problem has existed since at least commit 862172f45c (v2.12.0, 2017) - even back in that patch to start using a QIONetListener to handle listening on multiple sockets, nbd_server_free() was already unaware that the nbd_blockdev_client_closed callback can be reached later by a client thread that has not completed handshakes (and therefore the client's socket never got added to the list closed in nbd_export_close_all), despite that patch intentionally tearing down the QIONetListener to prevent new clients. Reported-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com> Fixes: CVE-2024-7409 Signed-off-by: Eric Blake <eblake@redhat.com> --- blockdev-nbd.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)