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
