Full Disclosure mailing list archives
Re: [inbox] Re: RE: Linux (in)security
From: Brett Hutley <brett () hutley net>
Date: Mon, 27 Oct 2003 10:23:54 +1100
Paul Schmehl wrote:
--On Sunday, October 26, 2003 12:45 PM -0500 Bill Royds <full-disclosure () royds net> wrote:Actually there is a significant difference between OS that get a large number of vulnerabilities released like Windows, Linux etc. and those OS like VMS and OS/400 that do not. The real difference is the programming language used to write the code. The C programming language used for Windows, Linux etc. is inherently insecure. The C string is an invitation to a buffer overflow. It has no bounds checking by default so each use of it (copy, string search ...) must be checked for a buffer overflow.You mean, as a programmer, it's not possible to write a library function that checks string lengths and simply call it for every buffer?Like (in pseudocode)? chk_str_len(buf) { if (buf>256) { print "Error! Input larger than allocated buffer!" return err_num }else{ return 0 }
*snip* Ahhh nope. What about the following? char buf[10]; const char *str1 = "OVER"; const char *str2 = "FLOW!!!!!"; sprintf(buf, "%s%s", str1, str2);Admittedly a contrived example. The best way to handle this type of stuff is to provide "safe" functions - like a sprintfn() that takes the maximum size of the buffer to write into as an argument. This function is reasonably tricky to write however. Consider the following example:
double x; char buf[10]; /* loop and add up some values in x */ sprintf(buf, "%f\n", x);Note that x has been accidently left uninitialized by the programmer. Now in testing the variable "x" happened to be initialized to zero, but whats say the stack happens to contain the value 123456780.9 in the area of memory that belongs to x when the function is called?
Also using these type of functions in operating system code is a good way to create a *REALLY* S L O W system. In maybe 80% of system code you are going to know who ALL the callers of the function are and are going to be working with input that has already been validated further up the call tree. Why slow this code down with unnecessary checks? Validation of input is important when the input is specified by something external to the system - user parameters, environment variables...
Cheers, Brett -- Brett Hutley [MAppFin,CISSP,SANS GCIH] mailto:brett () hutley net http://hutley.net/brett _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: [inbox] Re: RE: Linux (in)security Glenn_Everhart (Oct 23)
- RE: [inbox] Re: RE: Linux (in)security Curt Purdy (Oct 24)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Gregory A. Gilliss (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Valdis . Kletnieks (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Paul Schmehl (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Brett Hutley (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Ted Unangst (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Brett Hutley (Oct 26)
- Coding securely, was Linux (in)security Paul Schmehl (Oct 26)
- Re: Coding securely, was Linux (in)security coderman (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- Re: Coding securely, was Linux (in)security Valdis . Kletnieks (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Gregory A. Gilliss (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Bruce Ediger (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Stormwalker (Oct 27)