full-disclosure - Coding securely, was Linux (in)security

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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