Home page logo
/

bugtraq logo Bugtraq mailing list archives

And another qpopper overflow (does this make 3?)
From: agifford () INFOWEST COM (Aaron D. Gifford)
Date: Sun, 28 Jun 1998 01:42:25 -0600


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.



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]