|
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: 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 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 |
> Perhaps we should start development of a standardized 'safe' header file
> that can contain macros for snprintf, strncat and the like.
>
> Example:
> #define safe_snprinf(dst,len,fmt,var)
> snprintf(dst,(len>sizeof(dst)-1)?sizeof(dst)-1:len,fmt,var)
>
> #define safe_strcat(dst,src)
> strncat(dst,src,sizeof(dst))
>
> #define safe_strncat(dst,src,len)
> strncat(dst,src,(len>sizeof(dst)-1-strlen(dst))?
> (sizeof(dst)-1-strlen(dst):len)
This works only with arrays. But breaks with pointers,
because sizeof(pointer) returns 4 (32 bit machines) or 8 (64 bit machine)...
> Although it may be easier to rewrite the libraries with checks
> implemented...
that is snprintf() et al...
But these only give you the possibility to do something right.
But to do it right you have to know what you are doing...
> My argument is that we should move security into the libraries and tools
> and not rely on the developer to implement checks to avoid existing (but
> documented) flaws..
No.
The libraries must give the developer the tools he needs to
write save programs.
Only he knows the limitations his program has and needs.
And it is his responsibility to implement these limitations.
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
[ reply ]