Full Disclosure mailing list archives
Re: Coding securely, was Linux (in)security
From: Brett Hutley <brett () hutley net>
Date: Mon, 27 Oct 2003 14:35:02 +1100
Paul Schmehl wrote:
--On Monday, October 27, 2003 10:23 AM +1100 Brett Hutley <brett () hutley net> wrote: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.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...
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 () hutley net http://hutley.net/brett _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: [inbox] Re: RE: Linux (in)security, (continued)
- RE: [inbox] Re: RE: Linux (in)security Curt Purdy (Oct 24)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Gregory A. Gilliss (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Valdis . Kletnieks (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Paul Schmehl (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Brett Hutley (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Ted Unangst (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Brett Hutley (Oct 26)
- Coding securely, was Linux (in)security Paul Schmehl (Oct 26)
- Re: Coding securely, was Linux (in)security coderman (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- Re: Coding securely, was Linux (in)security Valdis . Kletnieks (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Gregory A. Gilliss (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Bruce Ediger (Oct 26)
- Re: [inbox] Re: RE: Linux (in)security Stormwalker (Oct 27)
- Re: [inbox] Re: RE: Linux (in)security Bill Royds (Oct 27)
- Re: [inbox] Re: RE: Linux (in)security Bruce Ediger (Oct 27)
- Message not available
- Coding securely, was Linux (in)security Paul Schmehl (Oct 26)
- RE: Coding securely, was Linux (in)security Chris Eagle (Oct 26)
- Re: Coding securely, was Linux (in)security Brett Hutley (Oct 26)