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

Valdis.Kletnieks@...edu wrote:

> On Mon, 27 Oct 2003 14:35:02 +1100, Brett Hutley said:
> 
> 
>>CALL STACK:
>>1: accept_user_input(); /* validate user input here */
>>2: processing_loop_with_user_input(); /* rather than here */
> 
> 
> Of course, validating in (1) rather than (2) introduces race conditions and
> the like (all sorts of TOCTOU issues, filesystem races, and the like), so
> you need to also be sure that what's validated in (1) is what's used in (2).

Yup. Important for multithreaded code, and code that accesses the 
filesystem or environment variables that can change after the check.

> Remember that most symlink races work *because* the checking is done in (1).

True. On the other hand if I accept input from a user and I require it 
to be under 256 chars in length and I copy it to either a stack or 
heap-based area of memory, I don't need to keep on checking that it 
STILL is under 256 chars in length a million times (especially when I'm 
writing code that is performance-critical).

I guess it all comes down to the CONTEXT the code is in. Which is why I 
object to blanket statements being applied to arbitrary bits of code. 
The requirements for the code at the time-critical parts of a device 
driver is completely different to the requirements for password 
validation routine.

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