[Libguestfs] [NBDKIT SECURITY] STARTTLS denial-of-service weakness

[Eric Blake]

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 at redhat.com>.

Reviewed by Rich Jones <rjones at redhat.com>.

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#security-considerations

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