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: <3F9C9266.5070708@hutley.net>
From: brett at hutley.net (Brett Hutley)
Subject: Coding securely, was Linux (in)security

Paul Schmehl wrote:

> --On Monday, October 27, 2003 10:23 AM +1100 Brett Hutley 
> <brett@...ley.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@...ley.net
http://hutley.net/brett