We have discovered a potential Denial of Service Attack in nbdkit, when using opportunistic TLS. Lifecycle --------- Reported: 2021-08-12 Fixed: 2021-08-18 Published: 2021-08-18 This has been assigned CVE-2021-3716. Credit ------ Reported and patched by Eric Blake <eblake(a)redhat.com&gt;. Reviewed by Rich Jones <rjones(a)redhat.com&gt;. Description ----------- nbdkit is a Network Block Device (NBD) server with multiple plugins, and includes the ability to do opportunistic (--tls=yes) or forced (--tls=require) encryption. While the NBD protocol already documents the risk of using opportunistic mode [1] (because neither the client nor the server can detect a meddler-in-the-middle [MitM] downgrade attack) and recommends forced TLS mode if downgrade attacks must be prevented, until recently, it had not considered other potential MitM effects beyond trivial modification of NBD_OPT_STARTTLS requests. [1] https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md#securi... An attacker can proxy all traffic between a client and server, and can inject plaintext commands to the server prior to the point that the client requests the transition to TLS with NBD_OPT_STARTTLS. By injecting a request for NBD_OPT_STRUCTURED_REPLY before encryption is started, the attacker will cause affected nbdkit versions in opportunistic TLS mode to send structured reply traffic during the encrypted session, thereby confusing a client that is unprepared for structured replies, even though both the client and the server assume that the connection is now safe from a MitM attack because the TLS request succeeded. Depending on how the client handles unexpected structured replies, the attacker can use this to form a denial of service attack on the client, distinct from a trivial protocol downgrade attack. Mitigating this is the fact that the attack is not possible if nbdkit is in forced TLS mode (--tls=require); and the NBD protocol already recommends using forced TLS in scenarios that want to protect against a MitM attack. Furthermore, a client that requests structured replies after encryption is enabled is not impacted (this includes qemu 2.12 and newer, and all versions of libnbd); the denial of service only occurs with TLS clients that do not understand structured replies (this includes qemu 2.8 through 2.11, and nbd-client 3.15 through the present). Similarly, it is possible to prevent the attack by arranging clients and servers to use a trusted network (for example, using nbdkit -U for a local Unix socket, rather than exposing the connection over TCP). Fixed versions of nbdkit ensure that the NBD_OPT_STARTTLS command now restores all server state back to the same settings as the original new client session, so that a client is guaranteed that once encryption is started, the only way to change the protocol sent over the wire is via subsequent changes triggered by encrypted negotiation between the client and server, without interference from a MitM attacker. Test if nbdkit is a vulnerable version -------------------------------------- At this time, there are no known readily-available open source clients which allow easy injection of NBD_OPT_STRUCTURED_REPLY prior to NBD_OPT_STARTTLS, thus no easy way to test for the vulnerability other than creating a custom client. Workarounds ----------- In general, it is recommended to use forced tls (--tls=require) to avoid MitM attacks in the first place. But if opportunistic encryption must be used (--tls=yes), it is recommended to upgrade to a fixed version of nbdkit, or to ensure that clients that want to use TLS will request structured replies after the encryption is enabled. If this cannot be done, apply network filtering (eg. firewall, TCP wrappers, etc.) or use a Unix domain socket instead of TCP to ensure that untrusted clients cannot connect to nbdkit as a MitM attacker. Fixes ----- This affects all nbdkit versions 1.12 through 1.26.4, as well as development versions through 1.27.5. A fix is available for the current development branch, and a followup email will give commit ids for each stable branch where the fix has been backported. https://listman.redhat.com/archives/libguestfs/2021-August/msg00077.html * development branch (1.27) use nbdkit >= 1.27.6 from http://download.libguestfs.org/nbdkit/1.15-development/ * stable branch 1.26 use nbdkit >= 1.26.5 from http://download.libguestfs.org/nbdkit/1.26-stable/ * stable branch 1.24 use nbdkit >= 1.24.6 from http://download.libguestfs.org/nbdkit/1.24-stable/ -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org