lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <3F9CAB45.6040704@hutley.net> From: brett at hutley.net (Brett Hutley) Subject: Coding securely, was Linux (in)security Chris Eagle wrote: >>-----Original Message----- >>From: Brett Hutley [mailto:brett@...ley.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@...ley.net http://hutley.net/brett
Powered by blists - more mailing lists