commit 463272eab866a36162fe51813327ca7af2f37ca0
Author: Oswald Buddenhagen <[email protected]>
Date: Wed Nov 24 19:21:48 2021 +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).
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;
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
