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(a)redhat.com&gt; and patched by Eric Blake <eblake(a)redhat.com&gt; 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/8d444b41d09a700c7ee6f9182a649f3... 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/9219d2e70c770d8efb98d6e8eaf68e8... 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/7ed8072a90922372dd1ba32bddd5526... 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/6c8f2f859926b82094fb5e85c446ea0... 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