|
Secure Programming
RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 01:00AM Michael Howard (mikehow microsoft com) (2 replies) RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 07:03PM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 07:36PM Casper Dik (Casper Dik Sun COM) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:10PM Andrew Griffiths (andrewg d2 net au) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 03:25AM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Mar 22 2003 09:56AM Casper Dik (Casper Dik Sun COM) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:22PM Andrew Griffiths (andrewg d2 net au) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 06:54PM John Viega (viega securesoftware com) (2 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 09:46PM Frank Knobbe (fknobbe knobbeits com) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 09:31AM Steffen Dettmer (steffen dett de) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 03:35PM Tim van Erven (tripudium chello nl) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 06:26PM Götz Babin-Ebell (babinebell trustcenter de) Re: Are bad developer libraries the problem with M$ software? Nov 16 2002 03:29PM Alex Lambert (alambert webmaster com) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 17 2002 01:46AM Glynn Clements (glynn clements virgin net) |
|
Privacy Statement |
> On Mon, 2002-11-18 at 17:10, Andrew Griffiths wrote:
>
> > Another thing to use is consistency, for example,
> >
> > char dst[50];
> > strncpy(dst, user_supplied_data, sizeof(dst));
> > strncat(dst, sizeof(dst) - strlen(dst) -1, moreuserdata);
> >
> > This could be exploitable if user_supplied_data is 50 or more bytes long.
> >
> > In specific,
> >
> > 50 - 50 - 1 == -1
>
> If sizeof(dst) is 50, then a 0 terminated string is is 49 chars long
> (len(dst) is 49). That means we've got 50-49-1 = 0 which is correct as
> there is no room left in dst.
>
> Of course in your example you allow dst to overflow in the strncpy.
> Using
> strncpy(dst, user_supplied_data, sizeof(dst)-1);
> would have prevented that if my math is correct.
No, it would not. strncpy does NOT append the trailing 0 if the
length of the source is greater than or equal to the count.
Using sizeof(dst)-1 will leave the last byte in the buffer unchanged.
If dst is on the stack there is no guarantee the string is terminated.
To be sure, you would *also* need to add
dst[sizeof(dst)-1] = 0;
C'mon people, this really is beginner stuff.
Please RTFM before you post well-meaning advice.
You might also like to look at the bsd-style strlcpy/strlcat functions.
[ reply ]