full-disclosure - Blacklist defenses as a breeding ground for vulnerability variants

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: Fri Feb  3 20:08:01 2006
From: coley at mitre.org (Steven M. Christey)
Subject: Blacklist defenses as a breeding ground for
	vulnerability variants

David Litchfield recently provided a detailed description of a number
of vulnerabilities in Oracle PLSQL Gateway.  He showed how, each time
the blacklist defense was modified, he was able to find a new variant
that worked around the more restrictive blacklist.

This type of pattern has emerged time and time again, in all classes
of software.  A lot of people know this, but I thought it would be
useful to cover a more general example.

An easily demonstrable example is related to cross-site scripting,
which has a rich variety of attacks that involve different syntactic
or semantic manipulations.  Blacklist-bypassing variants are
frequently found; this is probably one reason why XSS is so common,
and why some products seem to get hit with XSS issues again and again.

Suppose "Product X" is vulnerable to a basic XSS issue in which the
most obvious manipulation is used:

  <script>alert('hi')</script>

==== Patch 1 ====

A vendor's first fix might be to strip out all data between "<script>"
and "</script>" - i.e., use a blacklist of known-bad tags.

A subsequent attack might use this manipulation:

  <img src="javascript:alert('hi')">

==== Patch 2 ====

If Product X wants to support the image tag - which many do - then the
vendor might choose to strip out anything related to "javascript:"

The attacker's next manipulation might be:

  <img src="j&#X41vascript:alert('hi')">

which is rendered in some (all?) browsers.

==== Patch 3 ====

OK, so the vendor learns to decode all inputs first, *then* compare
them to "javascript:".

Then this non-standard manipulation would pass:

  <img src="javas
  cript:alert('hi')

A hard-coded newline in the middle of a "javascript" will fool a lot
of blacklist defenses, but still might be rendered by some browsers.

==== Patch 4 ====

OK, so the vendor FINALLY learns to ensure that ONLY "http" URIs are
allowed in the SRC IMG tag.

After THAT issue is fixed, the attacker might try this:

  <img src="http://www.example.com/pic.jpg" onmouseover="alert('hi')">

The src tag has an legitimate "http" URL, but the onmouseover
attribute causes problems.

==== Patch 5 ====

OK, so the vendor might extend the blacklist to strip out
"onmouseover" from IMG tags.

Whoops, what about onload?

  <img src="http://www.example.com/pic.jpg" onload="alert('hi')">

OK, so the vendor FINALLY learns a lesson about allowing arbitrary
attributes, and restricts img tags to *only* support src, and *only*
for "http" URLs.

==== Patch 6 ====

But maybe the blacklist doesn't apply this to *all* tags.

So the attacker might move to an otherwise innocent-looking tag:

  <b onmouseover="javascript:alert('hi')">HI THERE</b>

==== Patch 7 ====

Then the vendor finally decides to test all inputs against a
restricted set of supported tags and very limited attributes - i.e. a
whitelist.

**********
Conclusion
**********

Any number of variants could follow, even from this example.

The point is that if you use blacklists, eventually you could be
henpecked by attack variants until you are forced to use whitelists.