[7084] in bugtraq
And another qpopper overflow (does this make 3?)
daemon@ATHENA.MIT.EDU (Aaron D. Gifford)
Sun Jun 28 15:22:11 1998
Date: Sun, 28 Jun 1998 01:42:25 -0600
Reply-To: "Aaron D. Gifford" <agifford@INFOWEST.COM>
From: "Aaron D. Gifford" <agifford@INFOWEST.COM>
To: BUGTRAQ@NETSPACE.ORG
Thank you Miquel van Smoorenburg <miquels@CISTRON.NL> for explaining to me how
the UIDL handling in pop_dropcopy.c can potentially later result in a buffer
overflow. The first time I saw the patch for pop_dropcopy.c, I looked all
over pop_dropcopy.c and couldn't see any overflow. Then Miquel explained that
the overflow actually ocurrs in pop_udil.c but the prevention of the overflow
is by limiting the uidl length in pop_dropcopy.c.
After further investigation, I see another potential overflow in pop_uidl.c
that can occur even when uidl length is limited to 128 chars. The potential
overflow can occur in the pop_euidl() function in two different spots where
this code appears:
sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
if (nl = index(buffer, NEWLINE)) *nl = 0;
sprintf(buffer, "%s %d %s", buffer, mp->length, from_hdr(p, mp));
Even with mp->uidl_str limited to 128 chars, the from_hdr(p, mp) code can
return the text from a message's "From:" header which could then overflow the
buffer.
Also, is it just me, or is the from_hdr() function in the pop_uidl.c file
returning a pointer to a non-static buffer? That's wrong, is it not? It is
defined:
char buf[MAXLINELEN], *cp;
Should it not instead be:
char * cp;
static char buf[MAXLINELEN];
Enjoy!
Aaron out.
