All previously released versions of Sprockets, the software that powers the Rails asset pipeline, contain a directory traversal vulnerability. This vulnerability has been assigned CVE-2018-3760.
How do I know if I'm affected?
Rails applications are vulnerable if they have this setting enabled in their application:
# config/environments/production.rb
config.assets.compile = true # setting to true makes your app vulnerable
Note: The default value of this setting that ships with Rails in
production.rbisfalse. By default, Rails apps running in production mode are not vulnerable to this exploit.
How do I fix it?
To remediate this vulnerability, applications can either change the setting above to false or upgrade to the latest version of Sprockets. Heroku highly recommends upgrading to the latest patch release for your version of Sprockets by running bundle update sprockets. Make sure that the update puts your application on one of these Sprockets versions (or newer):
- 2.12.5
- 3.7.2
- 4.0.0.beta8
Here are instructions on how to upgrade your Sprockets version.
What was at risk?
If your application was targeted using this exploit and you had the assets.compile setting enabled on your production app, it's possible that secrets contained in your repo or your environment variables have been compromised. As a precaution, you may wish to rotate your database credentials, along with any other credentials stored in your application code or environment.
Instructions for rotating Heroku data services are below:
- Rotate Heroku Postgres credentials
- Rotate Heroku Key-Value Store credentials
- Rotate Heroku Kafka credentials
For other add-on partners, please check the specific add-on documentation for instructions on how to rotate credentials.
How does the exploit work?
Released in CVE-2018-3760, the directory traversal vulnerability was discovered by Orange Tsai from DEVCORE. To exploit the traversal, the app needs to have their assets set to compile at runtime.
When runtime compilation is enabled, a Sprockets server will dynamically check to see if an asset is rendered or not when it receives a request. If Sprockets can't find an already rendered asset, it will try to find and compile an asset that matches the request. The search process is very slow, and as such it is not a recommended best practice for this type of asset management software.
The directory traversal vulnerability exploits this search process to fool the Sprockets server. Using a known absolute path to the directory of a source asset, an attacker can craft a URL that convinces Sprockets it is rendering an asset inside one of its permitted paths.
Heroku's Involvement
The Sprockets issue was reported via the Rails security bug tracker on HackerOne by Orange Tsai. It was passed to the Rails maintainers, who forwarded the issue to Richard Schneeman, the current Sprockets maintainer; Richard Schneeman is also a Heroku employee, and the author of this post.
A patch was prepared for all three of the currently supported Sprockets versions: 2, 3, and 4. The patches were reviewed privately by the vulnerability reporter and other Rails core members. When the threat was determined to be sufficiently mitigated, a CVE was drafted, and there was a coordinated release of the CVE and the security patches.
When a severe security release that affects customers is announced, the CVE is passed to the Heroku security team and the vulnerability is given a score. Based on that score, the rest of the company determines what steps to take to best protect our customers. At the time of the CVE release, the knowledge of the security vulnerability by a Sprockets core member allowed us to quickly give it a score, and immediately begin developing a plan to communicate mitigation instructions to customers.
On June 19, we took the following actions to help ensure that customers likely to be affected were notified of the issue:
- Updated the Ruby Buildpack to fail builds for applications with runtime asset compilation enabled that are running an affected version of Sprockets.
- Contacted customers we know to be running Ruby on Rails applications that depend on Sprockets, as determined by our internal dependency tracking tool. Note that this tool may not always generate a complete list of affected applications; even if you did not receive an email, we urge you to carefully check your own dependencies to determine if you are affected.
If you cannot upgrade an affected Ruby application at this time but need to deploy, it is possible to regain deploy ability. This method is not recommended as it allows you to continue deploying a vulnerable application.
Accolades
Thank you to the original reporter of the security issue Orange Tsai, for patiently working with the core team while a release was coordinated. A safe and responsible disclosure ensured that our customers, and the entire Rails ecosystem, were not caught unaware without a security patch.
Thank you to the Rails security team for their tireless efforts reproducing and patching security bugs. This is difficult work that goes largely unseen by the general public, and as a result earns far too little appreciation.
Thank you to Heroku’s security team, for responding to the threat swiftly to protect our customers.
Finally, a thank you in advance to all of our affected customers, for upgrading their Sprockets versions and rotating their credentials.