Re: CPSN 4-970424: Possible buffer overflow in pop3d

[johan () BORG SVENTECH COM (Johannes Erdfelt)]

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