Critical Rails Bug Threatens to Derail Vulnerable Servers

An attacker could write arbitrary files and read sensitive files via images uploaded to the Rails Active Storage ImageMagick integration, possibly positioning a threat actor for lateral movement.

A critical vulnerability in Rails could send impacted Web servers off the tracks.

Rails, or Ruby on Rails, is a Web application framework built on Ruby. The framework's Active Storage component handles file uploads and can use the ImageMagick image processing suite to analyze uploaded images. And unfortunately, a flaw enables attackers to write arbitrary files to a Web server via ImageMagick.

The vulnerability (which is tracked as GHSA-f3w6-w445-fwh9) is critical, with a CVSS score of 9.8, and is considered so severe because an attacker could upload a crafted image file to write arbitrary files, read sensitive files, access secrets such as secret_key_base files, external system credentials, database passwords, and third-party tokens. These secrets could then be used for lateral movement or remote code execution into said external systems.

As a GitHub advisory published by the Rails maintainers explains, "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."

How Image Uploads Become an Attack Vector

The vulnerability exists because ImageMagick doesn't necessarily decide how to process a file (i.e., which coder it uses) based on the filename or extension, but rather on its contents. This means an attacker can upload an image file named "maliciousfile.jpeg" but contains content that causes ImageMagick to invoke a different coder. This can potentially allow arbitrary file reads or writes on the server.

Vulnerable versions of Active Storage include those 8.0 versions prior to 8.0.5.2 and 8.1 versions prior to 8.1.4.1. Those affected organizations running Rails applications that use ImageMagick for Active Storage image processing run with a security policy that does not block the affected coders, and accept uploads from untrusted users.

Active Storage patches are available now. The GitHub page includes further mitigation requirements for applications that use MiniMagick and ImageMagick.

Additionally, if an application stores attachments through the Disk service, users should "change secret_key_base and every secret readable by the application process, including the master key and everything config/credentials.yml.enc holds, storage and database credentials, and third-party tokens," the GitHub advisory said. Users should not retain exposed secrets as a fallback.

If a user requires a workaround, the GitHub page offers system rules the user can apply into ImageMagick's system policy.

Jake Knott, head of threat intelligence for exposure management vendor watchTowr, tells Dark Reading the firm has already reproduced the vulnerability in a lab environment, and "that against the right target, exploitation won't be difficult at all."

Moreover, he says he'd be surprised if public proof-of-concept exploit code took more than a few days to come to light.

"For attackers, reproducing the vulnerability here is likely the easy part, as the patterns and primitives involved in exploitation are well established," Knott says. "The hard part is finding software and deployments that are common enough, and configured in a vulnerable way, to deliver impact at scale indiscriminately."