Re: [Libguestfs] [libnbd PATCH] copy: Fail nbdcopy if NBD read or write fails
On Fri, Feb 04, 2022 at 09:26:09AM +0100, Laszlo Ersek wrote:
On 02/03/22 02:50, Eric Blake wrote:
> FIXME: This is CVE-2022-XXXXX (still awaiting assignment of the CVE number).
>
> nbdcopy has a nasty bug when performing multi-threaded copies using
> asynchronous nbd calls - it was blindly treating the completion of an
> asynchronous command as successful, rather than checking the *error
> parameter. This can result in the silent creation of a corrupted
> image in two different ways: when a read fails, we blindly wrote
> garbage to the destination; when a write fails, we did not flag that
> the destination was not written.
BTW: why is this a CVE? How is this exploitable for an attacker?
If you use nbdcopy over TCP without TLS (admittedly, that's already a
security risk you are taking by not using TLS), a MitM attacker can
inject a read or write failure to cause data corruption, and the
end-user of nbdcopy will receive no indication that it happened.
Users expect that if nbdcopy exits with status 0 and no messages, then
the destination should match the source.
I haven't ruled out whether an attacker could also corrupt a copy made
by TLS by aborting the stream at just the right moment before the end
of the transfer. On that front, nbd-ops.c looks like it will
generally fail the copy if nbd_shutdown() fails to clean up because
the connection was torn down prematurely, but it's difficult to prove
that there is no timing window where an attacker can manage to cause
the callback to nbd_aio_pread to fail while still being undetected by
nbd_shutdown.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org