Thread-topic: Blacklist defenses as a breeding ground for vulnerability variants
> -----Original Message-----
> From: Steven M. Christey [mailto:coley@xxxxxxxxx]
> Sent: Friday, February 03, 2006 11:08 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
> 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="jAvascript: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="; 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="; 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.
>
>
