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

[Wouter Verhelst]

On Thu, Aug 12, 2021 at 09:39:24AM -0500, Eric Blake wrote:
> 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.

This all makes sense, thanks.

-- 
     w at uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}