ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: 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="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.
> 
> 



 




Copyright © Lexa Software, 1996-2009.