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
| ||
|
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
Powered by blists - more mailing lists