[Full-Disclosure] Coding securely, was Linux (in)security

[Brett Hutley]

Paul Schmehl wrote:

> --On Monday, October 27, 2003 10:23 AM +1100 Brett Hutley 
> <brett at hutley.net> wrote:
> 
>>
>> 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...
>>
> If the input is *known* or has already been validated, why would you 
> need to check it?  My point is, if you can't know what the input will 
> be, you *must* check it.  The problem is that many programmers don't 
> think like hackers.  They write code as if every user will input the 
> correct data because, after all, they're trying to use it, not abuse it.

I completely agree with you here. I was trying to point out that 
implementing security in program code is more difficult than you made 
out with the "boilerplate buffer check" type approach. Of course this is 
a lot better than not checking user input at all.

> That, of course, fails with the first person who types something 
> incorrectly on the keyboard (intentionally or unintentionally) or when 
> the input from some device is different than what the programmer thought 
> it could ever be (for whatever reason.)

Indeed. Ideally the checks would occur at a high level in the call stack 
(this is ESPECIALLY important with operating system code) ie:

CALL STACK:
1: accept_user_input(); /* validate user input here */
2: processing_loop_with_user_input(); /* rather than here */

Cheers, Brett

-- 
Brett Hutley [MAppFin,CISSP,SANS GCIH]
mailto:brett at hutley.net
http://hutley.net/brett