server: CVE-2021-3716 reset structured replies on starttls
https://nostarttls.secvuln.info/ pointed out a series of CVEs in common implementation flaw in various SMTP and IMAP clients and servers, all with a common thread of improperly caching plaintext state across the STARTTLS encryption boundary; and recommended that other protocols with a STARTTLS operation perform a similar audit. It turns out that nbdkit has the same vulnerability in regards to the NBD protocol: when nbdkit is run in opportunistic TLS mode, an attacker is able to inject a plaintext NBD_OPT_STRUCTURED_REPLY before proxying everything else a client sends to the server; if the server then acts on that plaintext request (as nbdkit did before this patch), then the server ends up sending structured replies to at least NBD_CMD_READ, even though the client was assuming that the transition to TLS has ruled out a MitM attack. On the bright side, nbdkit's behavior on a second NBD_OPT_STRUCTURED_REPLY was to still reply with success, so a client that always requests structured replies after starting TLS sees no difference in behavior (that is, qemu 2.12 and later are immune) (had nbdkit given an error to the second request, that may have caused confusion to more clients). And there is always the mitigation of using --tls=require, which lets nbdkit reject the MitM message pre-encryption. However, nbd-client 3.15 to the present do not understand structured replies, and I have confirmed that a MitM attacker can thus cause a denial-of-service attack that does not trigger until the client does its first encrypted NBD_CMD_READ. The NBD spec has been recently tightened to declare the nbdkit behavior to be a security hole: https://github.com/NetworkBlockDevice/nbd/commit/77e55378096aa
parent
7182c47d
Please register or sign in to comment