[Full-Disclosure] Coding securely, was Linux (in)security
brett at hutley.net
Mon Oct 27 03:35:02 GMT 2003
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:
1: accept_user_input(); /* validate user input here */
2: processing_loop_with_user_input(); /* rather than here */
Brett Hutley [MAppFin,CISSP,SANS GCIH]
mailto:brett at hutley.net
Full-Disclosure is hosted and sponsored by Secunia.