isync

commit 463272eab866a36162fe51813327ca7af2f37ca0
parent 87065c12b477ee7239dd907f352dda5289c0c919
Author: Oswald Buddenhagen <ossi@users.sf.net>
Date:   Wed, 24 Nov 2021 19:21:48 +0100

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).

Diffstat:
M
src/drv_imap.c
 | 
5
+++++

1 file changed, 5 insertions(+), 0 deletions(-)
diff --git 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;