From 463272eab866a36162fe51813327ca7af2f37ca0 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Wed, 24 Nov 2021 19:21:48 +0100 Subject: [PATCH] CVE-2021-3657: reject excessively large IMAP literals we didn't limit the 32-bit size of literals so far, which, given that we use int-sized lengths & offsets, permitted all kinds of buffer overflows. malicious/compromised servers may have been able to exploit this. actual email senders would be constrained by size limits for delivered mails, and to cause more than a crash they'd have to predict the exact size of the final message. we now limit to 2GB, which, given that we use unsigned ints since e2d3b4d55 (v1.4.0), gives the handlers downstream plenty of headroom. an alternative would have been using 64-bit offsets, but this seems like major overkill, even if IMAP4rev2 recently mandated it (we talk only IMAP4rev1, so we can ignore it). --- src/drv_imap.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/drv_imap.c b/src/drv_imap.c index bd7a0f2..bb71506 100644 --- a/src/drv_imap.c +++ b/src/drv_imap.c @@ -877,6 +877,11 @@ parse_imap_list( imap_store_t *ctx, char **sp, parse_list_state_t *sts ) bytes = (int)(cur->len = strtoul( s + 1, &s, 10 )); if (*s != '}' || *++s) goto bail; + if ((uint)bytes >= INT_MAX) { + error( "IMAP error: excessively large literal from %s " + "- THIS MIGHT BE AN ATTEMPT TO HACK YOU!\n", ctx->conn.name ); + goto bail; + } s = cur->val = nfmalloc( cur->len + 1 ); s[cur->len] = 0;