[4371] in bugtraq
Re: CPSN 4-970424: Possible buffer overflow in pop3d
daemon@ATHENA.MIT.EDU (Johannes Erdfelt)
Tue Apr 29 00:14:37 1997
Date: Mon, 28 Apr 1997 11:18:36 -0400
Reply-To: Johannes Erdfelt <johan@BORG.SVENTECH.COM>
From: Johannes Erdfelt <johan@BORG.SVENTECH.COM>
X-To: Derric Scott <dtscott@scott.net>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199704280333.WAA29912@koala.scott.net>
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
