Libguestfs - Aug 2021 - [PATCH] docs: Link to protocol security considerations in uri docs

Especially useful in light of the recent publishing of
https://nostarttls.secvuln.info/, which documents a variety of
implementations vulnerable to downgrade attacks in SMTP and IMAP, as
well as its caution that that any protocol with a STARTTLS operation
(which includes NBD) needs to be aware of the potential downgrade
attacks.

The NBD protocol documentation already covers what is necessary to
avoid the effects of a downgrade attack, and all known implementations
of NBD servers and clients with working NBD_OPT_STARTTLS have at least
one mode where TLS is mandatory rather than opportunistic.  So I don't
see this as a CVE against the NBD protocol itself, so much as a worry
about the potential for future poor implementations that disregard the
documentation.
---

I'm likely to push this to the NBD spec later this week if it doesn't
receive any reviews beforehand.

 doc/uri.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/uri.md b/doc/uri.md
index 925ad4b..28aa94d 100644
--- a/doc/uri.md
+++ b/doc/uri.md
@@ -73,6 +73,12 @@ One of the following scheme names SHOULD be used to indicate
an NBD URI:
 Other URI scheme names MAY be used but not all NBD clients will
 understand them or even recognize that they refer to NBD.

+Note that using opportunistically encrypted connections (via the `nbd`
+or `nbd+unix` scheme) risks a protocol downgrade attack; whereas
+requests for a secure connection (via the `nbds` or `nbds+unix`
+scheme) MUST use TLS to connect.  For more details, see
+<https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md#security-considerations>
+
 ## NBD URI authority

 The authority field SHOULD be used for TCP/IP connections and SHOULD
-- 
2.31.1

On Tue, Aug 10, 2021 at 01:08:59PM -0500, Eric Blake
wrote:
> Especially useful in light of the recent publishing of
> https://nostarttls.secvuln.info/, which documents a variety of
> implementations vulnerable to downgrade attacks in SMTP and IMAP, as
> well as its caution that that any protocol with a STARTTLS operation
> (which includes NBD) needs to be aware of the potential downgrade
> attacks.
> 
> The NBD protocol documentation already covers what is necessary to
> avoid the effects of a downgrade attack, and all known implementations
> of NBD servers and clients with working NBD_OPT_STARTTLS have at least
> one mode where TLS is mandatory rather than opportunistic.  So I don't
> see this as a CVE against the NBD protocol itself, so much as a worry
> about the potential for future poor implementations that disregard the
> documentation.
> ---
> 
> I'm likely to push this to the NBD spec later this week if it
doesn't
> receive any reviews beforehand.
As a followup, I got this reply from Hanno B?ck on oss-security:

https://www.openwall.com/lists/oss-security/2021/08/11/8
| The buffering vulnerabilities we found are in STARTTLS implementations
| that have the expectation to enforce a secure connection, but suffer
| from various vulnerabilities in the implementation.

One of the reasons that SMTP and IMAP were particularly problematic in
implementations is that they are line-based protocols, with
arbitrary-sized packets where the length isn't known until the \n is
reached.  Both clients and servers have to choose whether to read one
character at a time (painfully slow) or read ahead into a buffer and
then processing what is in the buffer.  Many of the CVEs raised were
in regards to mishandling such buffers, such as acting on
previously-buffered plaintext even after the switch to encryption.

Thankfully, the NBD protocol has a much more structured handshake
(while different NBD_OPT commands can have different payload lenghts,
at least the header of each packet designates the length in advance,
reducing the need for read-ahead buffering), as well as documentation
that the NBD_OPT_ phase is a lockstep algorithm (neither client nor
server should be building up a buffer of more than one
command/response).

Another aspect of the SMTP/IMAP security holes came from incorrectly
carrying state across the transition to encryption (making a false
assumption that the answer made in plaintext will be the same when
encrypted).  Unfortunately, I have realized that the NBD spec has one
bit of state (NBD_OPT_SET_META_CONTEXT) where it is currently silent
on how to handle that state across a transition to encrypted.  So I
plan on posting a followup patch that matches the actual
implementation of nbdkit in opportunistic mode (qemu-nbd does not
offer opportunistic mode, and nbd-server does not suport
NBD_OPT_SET_META_CONTEXT): a server in opportunistic mode MUST treat
the NBD_OPT_STARTTLS command as wiping out any earlier
NBD_OPT_SET_META_CONTEXT.

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