Full Disclosure mailing list archives
Re: [inbox] Re: RE: Linux (in)security
From: Paul Schmehl <pauls () utdallas edu>
Date: Sun, 26 Oct 2003 16:15:21 -0600
--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 }Granted you probably want to be more gracious handling errors than an abrupt exit and you'd probably want to use a case statement to allow for checking numerous different allowed lengths, but seriously - is a language supposed to be goof proof? Or are programmers supposed to learn how to do it right?
How hard is it, really, to add a couple of lines to each input call - ok = chk_str_len(buf), if {ok == 0} continue}else{ handle_error(ok)}?
(I'm sure there are more efficient ways to handle this than my simplistic suggestion, but the point remains - handling buffer overflows should be trivial to write in C. The problem is that programmers simply don't think about it (or don't even know about it) when they're writing the code.
Isn't it the programmer's job to *know* what types he's using and what his pointers refer to? And if he can't know, to error check? It think we'd be vastly better off teaching how to program properly than we would be trying to devise a language that is idiot-proof. bAnother problem with C is that there is not an inherent mechanism to match the types of parameters in a fnction call with the types of the actual parameters used, especially when calling with arrays or pointers. A pointer argument is inherently insecure because it could point to anything. The only mechanism for passing parameters that need to be changed by a function is a pointer in C (others have value/result where the subroutine makes a local copy modifies that then returns the modified value for caller to use). If we really want to have more secure software we need to look at the tools we use to write it, not just at the platforms it runs on.
Paul Schmehl (pauls () utdallas edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu _______________________________________________ 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)