Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: CPSN 4-970424: Possible buffer overflow in pop3d
From: johan () BORG SVENTECH COM (Johannes Erdfelt)
Date: Mon, 28 Apr 1997 11:18:36 -0400


On Sun, 27 Apr 1997, Derric Scott wrote:

Is this security notice based on an exploit or is it just from examination
of the code.  My cursory glance indicates that there is no real threat from
that strcpy because the length of the input has already been checked before
execution reaches this point.  Ie:
        FUNCTION: svr_auth(state,inbuf), has the "offending" line:
                        strcpy(cli_user,inbuf);
        BUT:  svr_auth is called from MAIN with:
                        svr_state = svr_auth(svr_state,cli_buf);
        where cli_buf is read previously from stdin with:
                        if (fgetl(cli_buf,CLI_BUFSIZ,stdin) == NULL)

Now this machine doesn't have a manpage for "fgetl" but, from the arguments,
it looks like it will check the length...  so is there some OTHER way for
the bad guy to get the machine code into the buffer?  ALSO, cli_buf is
further worked on before that svr_auth call is made - the command is
shifted to lower case, it is scanned for a CR and trailing whitespace
is removed, etc. which may make it more difficult to put "code" in there.

fgetl is in util.c

Admittedly I scanned it very quickly, but it does look like the length of
the input is checked in "main."

You're right. This was mentioned in a number of email (including mine) to
the original poster. Although there was a strcpy, the information in inbuf
is controlled and doesn't pose a risk to buffer overflows.

JE



  By Date           By Thread  

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