From kragen@dnaco.net Tue Jul 14 11:41:50 1998
Date: Tue, 14 Jul 1998 11:41:49 -0400 (EDT)
From: Kragen <kragen@dnaco.net>
To: Kevin Vajk <kvajk@ricochet.net>
cc: security-audit@ferret.lmh.ox.ac.uk
Subject: Re: strcpy
In-Reply-To: <Pine.LNX.3.96.980714081645.20828A-100000@darkstar.localdomain>
Message-ID: <Pine.SUN.3.96.980714113514.22522N-100000@picard.dnaco.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Keywords:
X-UID: 511
Status: O
X-Status: 

On Tue, 14 Jul 1998, Kevin Vajk wrote:
> But there are certain types of buffer overflows that are virtually
> impossible for tools to detect.  Imagine a structure on the stack
> containing a character buffer and some uid's.  You might want to memcpy
> one of these onto another one of these.  How is this different from
> strcpy'ing into the string and overflowing into the uid's?  A tool really
> can't know.  

The compiler can.  If the code is something like:
struct x { char user[8]; int uid };
. . .
{
	struct x a, b;
	initialize(&a);
	memcpy((char*)&b, (char*)&a, sizeof(a));

. . . then it's obvious that the bounds of (char*)&a are intended to
include both a.user and a.uid.

On the other hand, if you say:
	memcpy(b.user, a.user, sizeof(a));

. . . it's apparent that the bounds of the pointers passed to memcpy
should not include uid, and this should result in an error.  This is
not a good idea anyway, since you have no assurance that whatever
compiler someone builds this code with will put uid after user anyway!

> The best answer is just to say that strcpy and friends are 
> not OK under any circumstances for setuid programs and network daemons.

Neither is strncpy(), then, because it fails to null-terminate the
string.  We are left with while (loop_conditions) *s++ = *t++.  I can't
believe this is an improvement.

Something like djb's stralloc stuff (part of qmail, which he's told me
I can use in other freed software; presumably other people would also
be able to) is really what is needed.

Kragen