Full Disclosure mailing list archives
Re: Coding securely, was Linux (in)security
From: Brett Hutley <brett () hutley net>
Date: Mon, 27 Oct 2003 16:21:09 +1100
Chris Eagle wrote:
-----Original Message----- From: Brett Hutley [mailto:brett () hutley net] So you're saying I don't need to worry if a file pointer is NULL before passing it through to fprintf()? So I don't need to worry if an argument to strcpy() is NULL? Or are you trying to say that the standard library is badly written?Nope, I never said the caller shouldn't check what they pass. But, the subroutine should NEVER assume that the caller has checked. I find it comical that others in this thread say in one breath, you should always validate user supplied input, but in another breath that subroutines should not be responsible for validating supplied parameters. A subroutine that states something like "never pass in a NULL pointer" and then chokes when someone does is poorly coded, plain and simple. If that applies to functions in the standard library then yes it is badly written. Undefined behavior in response to unexpected inputs is always a problem. Are you saying that subroutine authors should rely on the "good will" of callers to supply only valid arguments? Microsoft seems to take that approach regarding user input validation and it clearly doesn't work
The problem is that the creators of the standard library expect the users of the functions to use the appropriate functions for the job. For example; if I am copying a string to an area of memory that I have statically allocated as 256 bytes, and the input is coming from stuff that a user is typing in the following code might be appropriate:
char buf[256]; strncpy(buf, user_input, 256); buf[255] = '\0';BUT, I have also written code for many systems that REQUIRE fast code. One example is a system that accepts a market feed from a stock exchange and handles requests from a web server farm for the latest stock price. This code potentially has to handle hundreds of thousands of requests a second. Now I need the fastest possible code here - I am happy to validate my input before calling the functions, but I DON'T WANT my standard library's strcpy routine to test for NULL pointer arguments. Lets say the system forms a key by concatinating the stock exchange identifier with the stock code.
char buf[20]; const char *exchange_code = "ASX"; /* pre-validated as being 3 chars */ const char *stock_code = "BHP"; /* pre-validated as being <= 4 chars */ strcpy(buf, exchange_code); strcpy(buf+3, stock_code); /* search for key in tree before doing update... */The standard library SHOULDN'T check the arguments or I won't use it when I need to have fast code. I rely on having the standard library do the MINIMUM NEEDED to get the job done.
Failing to check the validation of untrusted user input is NOT THE SAME as not checking arguments to all functions. It's a horses-for-courses type of thing.
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: Coding securely, was Linux (in)security, (continued)
- Re: Coding securely, was Linux (in)security Brett Hutley (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)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 27)
- Re: [inbox] Re: RE: Linux (in)security Bruce Ediger (Oct 27)
- Message not available
- Coding securely, was Linux (in)security Paul Schmehl (Oct 26)
- RE: Coding securely, was Linux (in)security Chris Eagle (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- RE: Coding securely, was Linux (in)security Chris Eagle (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- Off topic programming thread Mortis (Oct 26)
- Re: Off topic programming thread Bill Weiss (Oct 27)
- Re: Off topic programming thread Chris Smith (Oct 27)
- RE: Coding securely, was Linux (in)security Paul Schmehl (Oct 26)
- Re: Coding securely, was Linux (in)security Bill Royds (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: Coding securely, was Linux (in)security Chris Eagle (Oct 26)
- RE: Coding securely, was Linux (in)security Steve Wray (Oct 27)
- Re: Coding securely, was Linux (in)security Gregory A. Gilliss (Oct 27)