Ruby on Rails flaw lets attackers write server files through crafted uploads

A flaw in Active Storage, the Rails framework for file uploads, can let an unauthenticated attacker write files on the server by uploading a crafted file. When attachments are stored with the Disk service, the attacker can also read files such as secret_key_base and credentials, which may lead to running code, Rails says. Rails rates it critical, and its advisory lists no CVE ID.

ImageMagick picks a coder from a file’s content, and some coders act on files named inside the image rather than on the image itself, Rails says. Active Storage restricted none of them, and its image analyzer runs as soon as a file is attached, so attaching the upload is enough. Rails has had one attack chain reported to it and doesn’t assume it’s the only one. Rails scores the flaw 9.8 under CVSS 3.0.

An app is exposed when it processes images with ImageMagick through the :mini_magick variant processor, the default for apps on load_defaults 6.1 or earlier. Its ImageMagick security policy must also leave the coders involved allowed, as the policies Debian and Ubuntu package do, and it must accept uploads from untrusted users. The fixed releases ship their own policy that denies the MSL scripting coder, the Ghostscript coders and the gs delegate, among others.

A second flaw, which Rails rates high, lets an uploaded file’s extension choose which FFmpeg or ImageMagick decoder processes it. With an FFmpeg built with AviSynth support, a .avs upload can expose files through the preview image or lead to running code. The FFmpeg packages in common Linux distributions and Homebrew don’t enable AviSynth, but the GPL builds from ffmpeg.org do, Rails says.

HackerOne researcher ryotak reported the ImageMagick flaw. The releases, out on Nov 3, fix 21 security issues in all, including a Strong Parameters bypass and several cross-site scripting flaws. Rails says versions older than 8.0 are unsupported, and security support for 8.0 ends on Nov 7.