|
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? Nov 19 2002 10:57PM Andrew Dalgleish (secprog andrewdalgleish dyndns org) (2 replies) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 03:31PM Frank Knobbe (fknobbe knobbeits com) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 07:11AM Valdis Kletnieks vt edu 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 |
>--=-WvvohHuyGg8bTtf96u13
>Content-Type: text/plain
>Content-Transfer-Encoding: quoted-printable
>
>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.
"strncpy" doesn't NUL terminate, so the strlen() in the above code can
return any value, including values *over* 50. Since the "n"
argument to strncat (which, incidentally, is the 3rd, not 2nd argument),
is unsigned, that would mean unlimited copying.
>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.
As long as you NUL terminated the string.
Casper
[ reply ]