Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
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 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[2]: Are bad developer libraries the problem with M$ software? Nov 21 2002 04:34PM
dullien gmx de
Hey John,
JV> 1) sizeof(dst) is very often going to be sizeof(char *) which is 2, no matter
JV> how much space is malloc'd.

Small correction: It should be 4 on most 32-bit platforms, possibly 8
on 64-bit address cpu's

JV> 2) Even if sizeof(dst) did give the right answer in all cases, your macro
JV> would still be susceptible to buffer overflows. Bascially, the third
JV> argument to strcat doesn't do what you seem to think it does. You'd
JV> need to make that: strncat(dst, src, sizeof(dst)-strlen(dst)-1),
JV> and even then you have to worry about whether dst has a null terminator
JV> (which it might not have depending on the call you used), and whether
JV> a null terminator will be placed on the string you're writing (won't
JV> happen if you fill the buffer exactly with some API calls).

Remember here then to document that the programmer must then never
never never use this call on an uninitialized stack buffer, as
strlen() could evaluate to be equal to sizeof() (assuming an attacker
has cleverly polluted the stack) and therefore strncat would copy
an arbitrary amount of data.

Cheers,
dullien (at) gmx (dot) de [email concealed]

--
Mit freundlichen Grüssen
dullien (at) gmx (dot) de [email concealed] mailto:dullien (at) gmx (dot) de [email concealed]

[ reply ]
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
Copyright 2009, SecurityFocus