From 138baebcae334c2c222c0d0299148fe1aef0315c Mon Sep 17 00:00:00 2001 From: Matthias Andree Date: Sun, 21 Aug 2011 15:07:48 +0200 Subject: Critical fix: don't embed NUL in unterminated last IMAP line. Found by Antoine Levitt. --- NEWS | 12 ++++++++++++ transact.c | 8 ++++++++ 2 files changed, 20 insertions(+) diff --git a/NEWS b/NEWS index e41a5682..54d8c0ba 100644 --- a/NEWS +++ b/NEWS @@ -56,6 +56,18 @@ removed from a 6.4.0 or newer release.) -------------------------------------------------------------------------------- +fetchmail-6.3.21 (not yet released): + +# CRITICAL BUG FIX +* The IMAP client no longer inserts NUL bytes into the last line of a message + when it is not closed with a LF or CRLF sequence. Reported by Antoine Levitt. + As a side effect of the fix, and in order to avoid a full rewrite, fetchmail + will now CRLF-terminate the last line fetched through IMAP, even if it is + originally not terminated by LF or CRLF. This bears no relevance if your + messages end up in mbox, but adds line termination for storages (like Maildir) + that do not require that the last line be LF- or CRLF-terminated. + + fetchmail-6.3.20 (released 2011-06-06, 26005 LoC): # SECURITY BUG FIXES diff --git a/transact.c b/transact.c index d1e4f6a9..ec8013a5 100644 --- a/transact.c +++ b/transact.c @@ -1435,7 +1435,15 @@ int readbody(int sock, struct query *ctl, flag forward, int len) * so we might end truncating messages prematurely. */ if (!protocol->delimited && linelen > len) { + /* FIXME: HACK ALERT! This \r\n is only here to make sure the + * \n\0 hunt works later on. The \n generated here was not + * part of the original message! + * The real fix will be to use buffer + length strings, + * rather than 0-terminated C strings. */ + inbufp[len++] = '\r'; + inbufp[len++] = '\n'; inbufp[len] = '\0'; + linelen = len; } len -= linelen; -- cgit v1.2.3