Critical Vulnerability in Rails Exposes Web Servers to Attacks

A critical vulnerability in Rails could severely compromise web servers that utilize the framework.

Rails, or Ruby on Rails, is a web application framework built on Ruby. Its Active Storage component manages file uploads and integrates with the ImageMagick image processing suite. A flaw in this integration allows attackers to write arbitrary files to a web server through ImageMagick.

This vulnerability, tracked as GHSA-f3w6-w445-fwh9, has a CVSS score of 9.8, indicating its severity. An attacker could upload a specially crafted image file to write arbitrary files, read sensitive information, and access secrets such as secret_key_base files, database passwords, and third-party tokens. Such access could facilitate lateral movement or remote code execution into external systems.

A GitHub advisory published by the Rails maintainers states, “A Rails application that processes attachments with ImageMagick may allow an unauthenticated attacker to write arbitrary files on the server and, when attachments are stored with the Disk service, to read arbitrary files readable by the application process.”

The vulnerability arises because ImageMagick processes files based on their contents rather than their filenames or extensions. This allows an attacker to upload an image file named “maliciousfile.jpeg” that contains content prompting ImageMagick to invoke a different coder, potentially enabling arbitrary file reads or writes on the server.

Versions of Active Storage affected include those prior to 8.0.5.2 and 8.1.4.1. Organizations running Rails applications that use ImageMagick for Active Storage image processing may be at risk if their security policies do not block the affected coders and if they accept uploads from untrusted users.

Patches for Active Storage are now available. The GitHub advisory also includes mitigation requirements for applications using MiniMagick and ImageMagick.

Furthermore, if an application stores attachments through the Disk service, users are advised to change the secret_key_base and all secrets readable by the application process, including the master key and contents of config/credentials.yml.enc, as well as storage and database credentials. Users should not retain exposed secrets as a fallback.

For those requiring a workaround, the GitHub page provides system rules that can be applied to ImageMagick’s system policy.

Jake Knott, head of threat intelligence for exposure management vendor watchTowr, reported that the firm has reproduced the vulnerability in a lab environment, indicating that exploitation against the right target could be straightforward.

Knott expressed concern that public proof-of-concept exploit code could emerge within days, stating, “For attackers, reproducing the vulnerability here is likely the easy part, as the patterns and primitives involved in exploitation are well established. The hard part is finding software and deployments that are common enough and configured in a vulnerable way to deliver impact at scale indiscriminately.”

Source: Dark Reading