=====[BEGIN-ACROS-REPORT]===== PUBLIC ========================================================================= ACROS Security Problem Report #2009-01-05-2 ------------------------------------------------------------------------- ASPR #2009-01-05-2: HTTP Header Injection in Ruby Core library ========================================================================= Document ID: ASPR #2009-01-05-2-PUB Vendor: Ruby (http://www.ruby-lang.org) Target: Ruby HTTP libraries Impact: The redirect_to function in Ruby Core library is vulne- rable to "CRLF injection", allowing an attacker to inject arbitrary HTTP response headers into the server's response. Severity: Medium Status: Official patch available, workarounds available Discovered by: Luka Treiber of ACROS Security Current version http://www.acrossecurity.com/aspr/ASPR-2009-01-05-2-PUB.txt Summary ======= The redirect_to function of Ruby Core library does not sanitize user supplied parameters passed to it, which can allow an attacker to inject arbitrary HTTP response headers into the server's response using CRLF injection. Many Rails applications should be vulnerable because redirect_to is commonly used for HTTP redirects in Rails applications. Product Coverage ================ * Rails 2.0 Note: Our tests were only performed on the above product version. Other versions may or may not be affected. Analysis ======== The Ruby HTTP libraries used by Rails do not perform any santization of the values of their HTTP Headers. This can lead to Response Splitting and Header Injection attacks in certain circumstances where user-provided values are written into response headers. These malformed values can be used to set custom cookies or forge fake responses to users if the application uses any of the user submitted parameters to construct HTTP headers without sanitizing. A common scenario where this can be exploited is where the application takes a URL from the query string, and redirects the browser to that URL. Many Rails applications on unpatched servers should be vulnerable because redirect_to is commonly used for HTTP redirects in Rails applications. Solution ======== To mitigate this threat new versions of Rails have been released, sanitizing the values passed to the redirect_to method. However one is still advised to take caution when writing other values to response headers. The new versions which contain the fixes are: -2.0.5 -2.1.2 -2.2.0 These releases are available for download, but patches patches are also available Workaround ========== Developers can neutralize attacks by employing their own sanitization code prior to calling the redirect_to function. References ========== [1] http://weblog.rubyonrails.com/2008/10/19/response-splitting-risk [2] http://www.rorsecurity.info/journal/2008/10/20/header-injection-and-response-splitting.html [3] http://github.com/rails/rails/commit/7282ed863ca7e6f928bae9162c9a63a98775a19d Acknowledgments =============== We would like to acknowledge Michael Koziarski [michael@koziarski.com] and the Rails team for professional handling of the identified vulnerability. Contact ======= ACROS d.o.o. Makedonska ulica 113 SI - 2000 Maribor e-mail: security@acrossecurity.com web: http://www.acrossecurity.com phone: +386 2 3000 280 fax: +386 2 3000 282 ACROS Security PGP Key http://www.acrossecurity.com/pgpkey.asc [Fingerprint: FE9E 0CFB CE41 36B0 4720 C4F1 38A3 F7DD] ACROS Security Advisories http://www.acrossecurity.com/advisories.htm ACROS Security Papers http://www.acrossecurity.com/papers.htm ASPR Notification and Publishing Policy http://www.acrossecurity.com/asprNotificationAndPublishingPolicy.htm Disclaimer ========== The content of this report is purely informational and meant only for the purpose of education and protection. ACROS d.o.o. shall in no event be liable for any damage whatsoever, direct or implied, arising from use or spread of this information. All identifiers (hostnames, IP addresses, company names, individual names etc.) used in examples and demonstrations are used only for explanatory purposes and have no connection with any real host, company or individual. In no event should it be assumed that use of these names means specific hosts, companies or individuals are vulnerable to any attacks nor does it mean that they consent to being used in any vulnerability tests. The use of information in this report is entirely at user's risk. Revision History ================ January 5, 2009: Initial release Copyright ========= (c) 2009 ACROS d.o.o. Forwarding and publishing of this document is permitted providing the content between "[BEGIN-ACROS-REPORT]" and "[END-ACROS-REPORT]" marks remains unchanged. =====[END-ACROS-REPORT]=====