[Techtalk] Theory vs. practice

[Julie]

Jenn Vesperman wrote:
> 
> On Wed, 2002-01-16 at 13:22, Julie wrote:
> 
> > What I think of as "security bugs" is code like this --
> >
> >       if (stat (file, blah) == 0 && blah.st_uid == me)
> >               chown (file, me, new_group);
> >
> > where the fact that there is a race between the stat and the
> > chown exists.
> 
> Except that there -shouldn't- be a race condition, because the
> conditional should be evaluated before the chown. If the conditional
> hasn't been evaluated, the code doesn't know whether to do the chown or
> not.

Jeff already gave away the answer, but that's more of a "security
bug" than

	char	buf[1024];
	char	prefix[1024];
	char	suffix[1024];

	gets (prefix);
	gets (suffix);
	strcat (strcpy (buf, prefix), suffix);

which is a pretty garden-variety way of (mis-) coding a buffer
overflow.

Years ago the attitude was "Well, if the user enters a string
=that= long they get what they deserve!".

The problem is that coders very seldom consider all of the
various assumptions they are making.  For example "No one is
going to type a 1K string!".  Okay, if that's what you're
assuming, test for it.

	char	buf[2048];
	char	prefix[1024];
	char	suffix[1024];
	char	*cp;

	if (! fgets (prefix, sizeof prefix, stdin) ||
			! (cp = strrchr (prefix, '\n')))
		return -1;

	*cp = '\0';

	if (! fgets (suffix, sizeof suffix, stdin) ||
			! (cp = strrchr (suffix, '\n')))
		return -1;

	*cp = '\0';
	
	strcat (strcpy (buf, prefix), suffix);

Look Ma, no buffer overflows ...

(The answer to file name race conditions is open(), fstat(),
fchmod(), fchown(), etc.)
-- 
Julianne Frances Haugh             Life is either a daring adventure
jockgrrl at austin.rr.com                 or nothing at all.
					    -- Helen Keller