fetchmail-friends
[Top] [All Lists]

[fetchmail]Bug report for overlong header-lines

2001-06-17 06:40:27

Hello,

there is a serious bug in fetchmail (5.8.6 and earlier versions, I
guess), which causes it to segfault, when the line of a message-header
exceeds MSGBUFSIZE (#defined to 8192). I'll attach the offending mail
in gzipped form at the end of this message. It's a spam mail (can't
even read it) which sucks per se. But if these things stop me from
accessing my other mail, I'm getting really angry.

Anyways, the problem is the completely screwed Content-Type
header. Such a message should really not make it through various
MTAs. But fetchmail should still be able to deal with the problem, I
think.

I'd locate the problem in 'readheaders' (file driver.c), where you can
find:

/*
 * At least one brain-dead website (netmind.com) is known to
 * send out robotmail that's missing the RFC822 delimiter blank
 * line before the body! Without this check fetchmail segfaults.
 * With it, we treat such messages as though they had the missing
 * blank line.
 */
if (!isspace(line[0]) && !strchr(line, ':'))
{
    headers_ok = TRUE;
    free(line);
    has_nuls = (linelen != strlen(line)); /* <- Unrelated Bug! */
    goto process_headers;
}

This block will be entered for the offending mail, because 'line'
contains the rest of the screwed up header. The first problem is that
free gets called while one line later strlen is applied on the same
buffer. But this did not cause the segfault (at least for me). But the
header is accepted and further parsing of the header is stopped. The
segfault happened later for me in stuffline (file sink.c) in the loop:

/* The line may contain NUL characters. Find the last char to use
 * -- the real line termination is the sequence "\n\0".
 */
last = buf;
while ((last += strlen(last)) && (last[-1] != '\n'))
    last++;

I'm willing to attempt to fix the problem myself, but since I'm
completely new to fetchmail development, I prefered to ask beforehand,
if this is a known problem. Or if someone else is currently rewriting
the code.

I think there are several options for fixing the problem:

- Make MSGBUFSIZE larger and hope noone will ever send an email, which
  triggers the problem again ;-) (not really a serious option...)

- Do not use a fixed buffer, but instead allocate it dynamically. May
  be difficult since other code may rely on the fixed size.

- Cut the line and ignore anything exceeding MSGBUFSIZE.

- Do not process such a message and signal an error.

Any ideas?

Thanks and regards,

Stephan

PS: If this message sounds too angry, don't get me wrong: I'm using
fetchmail now for quite some time to fetch my personal email as well
as various mail-boxes for smaller companies. And it always worked fine
for me. It's by far the most capable and flexbile solution to simply
fetch or shuffle around email, when you have a box somewhere.

Attachment: bug-mail.txt.gz
Description: Mail causing the problem

<Prev in Thread] Current Thread [Next in Thread>
  • [fetchmail]Bug report for overlong header-lines, Stephan Krings <=