fetchmail-friends
[Top] [All Lists]

[fetchmail] segfaults in fetchmail-6.2.2 - possible patch

2003-06-17 00:31:41
Hi!

I'm not sure if messages from those not subscribed to the list ever show up in
the list so I may repeat certain things that I have written earlier (before
subscribing :)

My problem was (hopefully was) that from time to time fetchmail-6.2.2 would
segfault. After restart it would download all messages without any problem
(no messages were lost). I changed it slightly to get a coredump and after
looking at coredump it appeared that there was some buffer overflow somewhere
in the code. 

Looks like I've found at least one place where this can happen.
Please review my patch attached below. 

Basically I got the impression that the code, that reads headers from the
socket and stores them in memory, is very risky. This code blindly assumes
that there will be never a combination of "\n\0" in the headers. As far as I
could see this combination is assumed as end of headers mark. (I won't talk
about stupid POP implementations that would pass such combinations in headers,
I hope this is rare :) But if the option "mimedecode" is set (as it is in my
case) then all mime encoded lines are decoded and these can leave behind
anything really. In some spam emails there are zero-terminated subject lines
and so on. In one particular case segfalt happened because the very last
header line contained mime-encoded text that after decoding introduced '\0' in
the line. The code for copying header from buffer into the line copied
everything up to this first zero-byte, leaving termninating "\n\0" outside. As
result the function stuffline didn't find the end of headers and segfaulted.
(It could find of course some other "\n\0" combination and then there would be
no segfault, just strange looking header :)

The patch should fix partly the problem described above. At least it will
always provide terminating "\n\0" at the end of headers. It does not protect
against extra "\n\0" introduced by mimedecoding. Which is probably not so
critical because this would result most likely in some error and not segfault.

Andrei

Attachment: fetchpatch.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>