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>] [day] [month] [year] [list]
Date: Mon, 10 Nov 2003 16:46:07 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: babin-ebell@...stcenter.de
Cc: bugtraq@...urityfocus.com
Subject: Re: Six Step IE Remote Compromise Cache Attack



"Goetz Babin-Ebell" <babin-ebell@...stcenter.de> said:

>> We need a little bit more than that, because our understanding of
>> "what's bad" increases with time, and that frequently reduces the set
>> of "what's good."
>
>Yes.
>But wrongly rejecting good input has no security implications.

Actually, I'm starting to see evidence that it can, if you think of
"susceptibility to denial of service" as a security issue.

Specifically, the software not only has to recognize the bad input, it
has to generate an error condition, then properly respond to it.

A few types of vulnerabilities have been reported due to bad error
handling on security-relevant conditions:

- An application detects an input that's too long and returns a NULL
  pointer, which then causes a crash when the pointer is dereferenced.

  In fact, I suspect that some of the so-called "buffer overflows"
  that get reported these days are really null pointer problems.
  Researchers are encouraged to consider this in their diagnoses.

- An application detects a bad input and reports an error, but it
  doesn't "exit" out of the code, and goes right on processing the bad
  input.

>I don't think we should primarily look for vulnerabilities,
>but we all should spend more time on the definition of allowed input
>and reject all that is not in these limits.

I agree that more attention should be paid to identifying *exactly*
what "allowed input" means.  For example, directory traversal issues
could probably be entirely eliminated as a class if the software's
design restricted file names to be alphanumeric with a single file
extension.  The programmer may cry "but that limits flexibility in
file naming!" but it's in that flexibility where danger lies.

On the other hand, alphanumeric tests can be insufficient if you also
want to avoid MS-DOS device name problems...

- Steve


Powered by blists - more mailing lists