Rails 3 security patch

Both vulnerabilities allow an attacker to execute a cross-site scripting attack by sending specially crafted input to vulnerable applications. The denial-of-service vulnerability, tracked as CVE , is located in the header handling component of Action View and allows an attacker to force an application to cache strings sent in specially crafted headers.

At this point the volunteer team of the Rails community that supports and maintains Rails will no longer provide security updates against critical security vulnerabilities. Once community support for a popular version of Rails ends, Rails LTS takes over maintenance and continues to provide security patches.

When a new advisory is posted to the official Rails security list or reported to us directly , we will patch the vulnerability and release a new version of the Rails LTS gems. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below.

To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters. Copy link. His post can help you figure out. Thanks Matt! Sign up for free to join this conversation on GitHub.

Already have an account? Carefully crafted requests can impact the data returned by the scheme method on Rack::Request. Applications that expect the scheme to be limited to "http" or "https" and do not escape the return value could be vulnerable to an XSS attack. Note that applications using the normal escaping mechanisms provided by Rails may not impacted, but applications that bypass the escaping mechanisms, or do not use them may be vulnerable.

All users running an affected release should either upgrade or use one of the workarounds immediately. Attackers may be able to find and hijack sessions by using timing attacks targeting the session id.

Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session. The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison. The session id stored in a cookie is the same id that is used when querying the backing session storage engine.

Most storage mechanisms for example a database use some sort of indexing in order to speed up the lookup of that id. By carefully timing requests and session lookup failures, an attacker may be able to perform a timing attack to determine an existing session id and hijack that session.

Specially crafted requests can be used to access files that exist on the filesystem that is outside an application's root directory, when the Sprockets server is used in production.