Re: Six Step IE Remote Compromise Cache Attack

["Steven M. Christey" <coley () mitre org>]

"Goetz Babin-Ebell" <babin-ebell () trustcenter 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