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]

From: cseagle at redshift.com (Chris Eagle)
Subject: Coding securely, was Linux (in)security

> -----Original Message-----
> From: Brett Hutley [mailto:brett@...ley.net]
>
> So you're saying I don't need to worry if a file pointer is NULL before
> passing it through to fprintf()? So I don't need to worry if an argument
> to strcpy() is NULL? Or are you trying to say that the standard library
> is badly written?

Nope, I never said the caller shouldn't check what they pass.  But, the
subroutine should NEVER assume that the caller has checked.  I find it
comical that others in this thread say in one breath, you should always
validate user supplied input, but in another breath that subroutines should
not be responsible for validating supplied parameters.  A subroutine that
states something like "never pass in a NULL pointer" and then chokes when
someone does is poorly coded, plain and simple.  If that applies to
functions in the standard library then yes it is badly written.  Undefined
behavior in response to unexpected inputs is always a problem.

Are you saying that subroutine authors should rely on the "good will" of
callers to supply only valid arguments?  Microsoft seems to take that
approach regarding user input validation and it clearly doesn't work

Chris