antirez <antirez(_at_)invece(_dot_)org>:
in the file pop3.c you can read:
else if (sscanf(buf, "%d %s", &num, id) == 2)
id is a stack allocated buffer of IDLEN+1 bytes
buf is server(attacker) supplied data of POPBUFSIZE+1 bytes
from fetchmail.h:
#define POPBUFSIZE 512 /* max length of response (RFC1939) */
#define IDLEN 128 /* max length of UID (RFC1939) */
The bug seems not exploitable because the stack layout in this
function prevents the return address corruption.
If you change the order of the declaration of "buf" and "id" you will
get a standard exploitable stack overflow.
It seems also that there are a very high number of insecure functions
call in fetchmail, not exploitable since the coder joked
with the size of the buffers and so on to prevent problems: warning,
with this approach some day you will get a security problem.
Please, for reply CC me since I'm not subscribed to the list.
If you want to send me patches to seal off any of these vulnerabilities,
I'll cheerfully take them.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Our society won't be truly free until "None of the Above" is always an option.