[Libguestfs] LIBNBD SECURITY: Silent image corruption with nbdcopy

Mon Feb 7 19:40:18 UTC 2022

We have discovered a security flaw with potential moderate impact in
libnbd.

Lifecycle
---------

Reported: 2022-01-24  Fixed: 2022-02-04  Published: 2022-01-27

This has been assigned CVE-2022-0485.

Credit
------

Reported by Nir Soffer <nsoffer at redhat.com> and patched by Eric Blake
<eblake at redhat.com>

Description
-----------

libnbd is a Network Block Device (NBD) client library.  nbdcopy is an
application shipped as part of the libnbd project designed to copy
files (typically disk images) where at least one of the source or
destination locations is an NBD server.

A flaw in the nbdcopy program silently ignored any asynchronous read
or write errors reported by an NBD server.  With no error messages and
no change to the exit status, a client of the nbdcopy application has
no indication that the corruption occurred, where the loss of data
integrity may have further implications in a denial of service attack
against disk images.  What's more, in some NBD client/server
configurations, the data that nbdcopy writes to the destination image
could come from uninitialized heap data in the nbdcopy process, where
the leaked information may aid in mounting a more sophisticated attack
against a machine using a long-running nbdcopy.

If TLS is not in use, a meddler-in-the-middler attacker can easily
corrupt the destination image by faking error replies to NBD read and
write commands.  But even when TLS is in use, the nature of the flaw
means that nbdcopy cannot detect legitimate error reports from the
server.  Furthermore, even though nbdcopy attempts to detect abrupt
disconnection of a TLS connection, the nature of asynchronous commands
means that we were unable to rule out whether a well-timed MitM
attacker could cause undetected corruption near the end of a copy
process by aborting a TLS stream at the right moment, even without
having access to the content of the TLS stream.

Test if libnbd is vulnerable
----------------------------

With nbdkit 1.14 or later installed, the following serves as an easy
test of the vulnerability:

$ nbdkit -U - --filter=error pattern size=1M error-pread-rate=1 \
  --run 'nbdcopy $uri null:' && echo vulnerable

The error messages printed from nbdkit demonstrate the failed NBD
transactions.  Where a vulnerable version of nbdcopy ignores those
errors and results in 'vulnerable' being printed to stdout, a fixed
version will diagnose a read failure to stderr.

Workarounds
-----------

Use of 'nbdcopy --synchronous' will avoid undected data corruption,
but comes at a potential performance cost by avoiding the speed
benefits of asynchronous operations.  If your version of nbdcopy lacks
the '--synchronous' command-line option (all 1.4.x releases), it is
not vulnerable.

Connecting a vulnerable version of nbdcopy to an NBD server that
supports structured replies by default (such as qemu-nbd 2.11 or
nbdkit 1.12 and newer) does not eliminate the risk of data corruption
on an error, but is sufficient to guarantee that any corruptions will
either read as all zeroes or else as prior contents of the destination
image.  This is safer than connecting nbdcopy to an NBD server that
lacks structured replies (such as nbd-server 3.23, current as of this
notice), where the data corruption could also leak heap contents from
the nbdcopy process.

Although the use of TLS does not avoid the bug, it is still
recommended to use TLS when utilizing nbdcopy to copy files across
machines, so that the NBD server can be trusted to not be malicious.

It is recommended to apply the fix or upgrade to a fixed version.

Fixes
-----

The flaw was introduced in libnbd 1.5.6 (commit bc896eec4d), when
nbdcopy gained the ability to default to using asynchronous NBD reads
and writes.  A fix for the missing error detection is available for
all affected stable branches, and the current development branch.

However, note that the stable-1.6 branch of libnbd has other known
data corruption bugs when communicating with an NBD server that
supports trim operations, which were repaired for 1.8 but not
backported to any 1.6.x release.  While the trim bug did not amount to
a CVE, if your reason for upgrading libnbd is to get a version of
nbdcopy that avoids known data corruption issues, it is recommended
that you use a newer release.

* development branch (1.11)

https://gitlab.com/nbdkit/libnbd/-/commit/8d444b41d09a700c7ee6f9182a649f3f2d325abb
  or use libnbd >= 1.11.8 from
  http://download.libguestfs.org/libnbd/1.7-development/

* stable branch 1.10

https://gitlab.com/nbdkit/libnbd/-/commit/9219d2e70c770d8efb98d6e8eaf68e8e354631e3
  or use libnbd >= 1.10.4 from
  http://download.libguestfs.org/libnbd/1.10-stable/

* stable branch 1.8

https://gitlab.com/nbdkit/libnbd/-/commit/7ed8072a90922372dd1ba32bddd5526e2d0a42de
  or use libnbd >= 1.8.7 from
  http://download.libguestfs.org/libnbd/1.8-stable/

* stable branch 1.6

https://gitlab.com/nbdkit/libnbd/-/commit/6c8f2f859926b82094fb5e85c446ea099700fa10
  or use libnbd >= 1.6.6 from
  http://download.libguestfs.org/libnbd/1.6-stable/

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org