bugtraq - RE: Six Step IE Remote Compromise Cache Attack

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-next>] [day] [month] [year] [list]

Message-ID: <200311072031.hA7KVw1k024556@linus.mitre.org>
Date: Fri, 7 Nov 2003 15:31:58 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: RE: Six Step IE Remote Compromise Cache Attack

Paul Schmehl said:

> We need a paradigm shift in programming from "allow all but the
> known bad" to "disallow all but the known good", don't we?

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."

For example, I recently audited a web application that inherently
disallowed all but known good inputs, by design.  Some of you know how
much of a rare pleasure it can be to audit well-designed software ;-)
It kept close track of "immutable" fields and would exit whenever any
tampering was detected.  It did a pretty good job of using regular
expressions to restrict input.

Unfortunately, it was subject to a CRLF injection vulnerability, which
was not publicly known at the time the application had been developed.
And the CRLF injection attack normally would not have worked thanks to
the app's design, except the web application had a "feature" (perhaps
accidental) in which a customized control file could define new fields
that should have been labeled immutable, but were not.

As a different example, consider directory traversal issues in which
".." sequences are separated by illegal characters that are filtered
out only *after* the ".." check is performed.  The process goes like:

  1) Software checks for ".." sequences and generates an error if any
     are found

  2) Software cleanses and canonicalizes the input

Such software could be subject to directory traversal via a ".|."
sequence that isn't found in step 1, but the "|" gets removed in step
2; or maybe a "%2e%2e" URL encoding would work.

While this may be an example of an "allow all but known bad" approach,
there are also lessons to be learned about designing the software so
that security-sensitive operations are performed in the proper order.
In addition, there's a need to know and explicitly model which
vulnerabilities a piece of data may be exposed to at different points
in time.  It's not just "known good," it's "known good under a
specific context at a specific time."

- Steve