On Fri, Nov 06, 2026 at 07:43:35PM +0000, Daniel P. Berrangé wrote: > On Fri, Nov 06, 2026 at 01:27:34PM -0600, Eric Blake wrote: > > Not all NBD protocol violations are equal. If a malicious server or > > client can trigger a QEMU assertion failure on a plaintext connection, > > but can be trivially mitigated by enabling TLS to weed out untrusted > > partners that would violate the protocol in the first place, then the > > bug does not need to be embargoed. Spell this out in our policy. > > > > Signed-off-by: Eric Blake <[email protected]> > > --- > > docs/system/security.rst | 24 ++++++++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/docs/system/security.rst b/docs/system/security.rst > > index e211fdd2344..29bb3e9b2a1 100644 > > --- a/docs/system/security.rst > > +++ b/docs/system/security.rst > > @@ -143,6 +143,17 @@ an issue as a normal bug. > > which case plain manipulation of the stream is not considered as > > an attack vector. > > > > +* **network protocols**. In scenarios involving a network connection, > > + such as NBD block devices, some bugs might be triggered when a > > + malicious server or client on the other side of the connection > > + intentionally violates the expected protocol. However, to be > > + considered as a security attack vector, the bug must be reproduced > > + prior to QEMU completing a TLS handshake with the remote partner. If > > + the bug relies on a plaintext connection, or can only be triggered > > + after first successfully negotiating TLS to filter out untrusted > > + connections, then it will be treated as a hardening bug but not a > > + security flaw. > > I don't think we can be so broad in ruling out these flaws > as security bugs, merely by performing an authorization > check of the client via a TLS certificate. > > This works in the case of live migration, because both sides > of the network connection are inherently operating at the same > privilege level, as they both have full access to the QEMU VM > workload. > > In the case of NBD, an authorized client can still be considered > to operate at a lesser privilege level than QEMU. We can have > exported 1 disk via NBD, but if the authorized client expoits > a bug in QEMU and thus accesses unrelated data that is still > a privilege violation.
Makes sense. Even a crash is thus a denial of service - while the misbehaving client is not accessing data it is not entitled to, it is taking out the rest of the qemu process which is beyond the bounds of what remote storage clients should be able to do. > > > In the NBD case, an example where we could rule out a security > issue, is if an NBD protocol exploit leaked a disk sector for > the dis that was already exported over NBD, as it would not > be giving info that the NBD client was not already authorized > to have. > > Many (possibly most) NBD bugs, however, I think will end up > being security issues. If they have a "low" severity, however, > we can rule our security handling via our catch all rule. I was trying to lean more into the aspect that if an NBD bug triggers a crash, BUT the bug is only reachable from a code path where a properly-configured QEMU that is enforcing TLS and x509 authentication can restrict access to non-compliant clients, then it is a low severity bug. But given that we already have a paragraph on no embargo for low severity, I would be fine with v2 leaving out this proposed paragraph and instead just focusing on documenting the need to utilize TLS and authorization as a way to reduce bug severity. > > > > * **uninitialized stack variables**. If the bug scenario relies on > > undefined behaviour from stack variables that lack explicit > > initialization, it will not usually be considered a security flaw. > > @@ -320,3 +331,16 @@ encryption and authorization control policy on client > > connections. > > In summary, the monitor console is considered a privileged control > > interface to > > QEMU and as such should only be made accessible to a trusted management > > application or user. > > + > > +Block device network protocols (NBD, NFS, etc.) > > +''''''''''''''''''''''''''''''''''''''''''''''' > > + > > +When using QEMU to access remote storage over a network (such as QEMU > > +acting as an NBD or NFS client) or to provide remote storage access > > +(such as QEMU acting as an NBD server), it is important to realize > > +that an unencrypted connection can allow an external process a > > +potential attack vector over the network port. The general > > +recommendation is that if the protocol allows the use of TLS, then the > > +management application must configure the use of TLS, in order to > > +limit the impact of unauthorized or man-in-the-middle attacks to the > > +smaller region of time before the TLS handshake takes place. > > Performing TLS only protects against a MITM attack by default. > > To protect further scenarios we must document that the protocol > must have x509 client certificates issued to authorized clients > and the tls-creds-x509 object set 'verify-peer=on' to check > them, potentially also 'tls-authz' to filter which certificates > are allowed if the CA issues certs more broadly. I'll rework this additional information into a v2 patch. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
