GHSA-F3W6-W445-FWH9: Rails Active Storage ImageMagick image analysis: arbitrary file write and read possible RCE

Active Storage image analysis: arbitrary file write, arbitrary file read, and code execution through ImageMagick's MSL scripting coder reached from an attached upload.

activestorage hands every attached upload to ImageMagick for image analysis without constraining which of ImageMagick's coders the file may reach. ImageMagick selects a coder from the content of the file it is given, and some coders act on files named inside the image rather than on the image itself. A file whose content is XML is sniffed as SVG (ImageMagick's built-in magic table maps ?xml/?xml/SVG/svg at offset 1 to the SVG coder), and ImageMagick's own SVG renderer resolves the xlink:href of every <image> element through ReadImage. Because that reference may carry an explicit coder prefix, an uploaded SVG containing <image xlink:href="msl:/path/to/file"/> makes ImageMagick parse the named file with the MSL ("Magick Scripting Language") coder. MSL is a scripting coder that reads and writes the files its script names, so the upload alone — no variant, preview, or analyze call — gives an unauthenticated attacker arbitrary file write, and (with the Disk service, where the attacker's own blob path is knowable) arbitrary file read.

This run reproduced the full chain against the real product code: activestorage at the parent of the fix commit, driven through a real HTTP upload endpoint, with a real Puma server, a real Active Storage Disk service, the real ImageMagick analyzer, and a real ImageMagick process. It also demonstrated escalation to code execution by writing the attacker's content into a path the application loads and renders.

• Component: activestorage (Ruby on Rails) — ActiveStorage::Analyzer::ImageAnalyzer::ImageMagick and, more fundamentally, the absence of any ImageMagick coder restriction in Active Storage.
• Affected versions: activestorage < 8.0.5.2 and >= 8.1, < 8.1.4.1; an application is affected only when all of the following hold:
  1. config.active_storage.variant_processor = :mini_magick (default for load_defaults 6.1 or earlier; the same setting selects the analyzer),
  2. ImageMagick runs under a policy that does not deny the coders involved (the policies shipped by Debian and Ubuntu do not deny MSL),
  3. untrusted users can attach uploads.
• Risk level: critical (advisory CVSS 3.0 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Consequences observed in this run: attacker-chosen file written at an attacker-chosen path with attacker-chosen bytes; files readable by the application process read and exfiltrated over HTTP (the process environment including SECRET_KEY_BASE, and a planted credential file); attacker-supplied Ruby executed inside the application process.

Impact Parity

• Disclosed/claimed maximum impact: the advisory asserts arbitrary file write and arbitrary file read when attachments are stored with the Disk service, and states that readable secrets "may in turn allow escalation to remote code execution". The submitted claim contract expects code_execution on the api_remote surface.
• Reproduced impact from this run:
  • arbitrary file write — full (exact attacker bytes at an attacker-chosen absolute path),
  • arbitrary file read — full (a planted credential file and /proc/self/environ including SECRET_KEY_BASE, both exfiltrated over HTTP through the attacker's own blob),
  • code execution — demonstrated (unique marker file content plus id output reflected in an HTTP response).
• Parity: full.
• Not demonstrated / conditions: the code-execution leg required the write target to be a path the application loads and re-reads, which the reproduced application has because it runs with code reloading enabled (Rails development defaults). The advisory-asserted write and read primitives are unconditional. A deployment with eager loading, template caching, and a non-writable application tree would still be fully exposed to arbitrary file write and read; its escalation to code execution would then depend on the deployment (a scheduled job, a writable autoload path, an executable script, ld.so.preload for a root-run process, and so on) and was not separately validated here.

Root Cause

1. Coder selection is attacker-controlled. ActiveStorage::Analyzer::ImageAnalyzer::ImageMagick#read_image downloads the blob and runs MiniMagick::Image.new(file.path) (i.e. magick identify on the file). Nothing in Active Storage restricts the set of coders ImageMagick may pick, so the uploader decides which parser handles the bytes. ImageMagick's built-in magic table maps XML-looking content to the SVG coder.
2. The SVG coder resolves references through ImageMagick's read path. coders/svg.c stores the xlink:href of <image> in svg_info->url and passes it to StrictReadImage()/ReadImage() (and emits image Over x,y w,h "url" into the MVG it renders). An explicit coder prefix in that reference is honoured, so msl:<path> selects the MSL coder for the named file.
3. MSL acts on files named inside the script. coders/msl.c implements <read> and <write>: read calls ReadImage on any filename (raw coders such as gray: read the file's bytes verbatim) and write calls WriteImage to any path. Both run with the privileges of the Rails process.
4. The Disk service makes the primitive remotely useful. The blob key is recoverable by decoding the signed (not encrypted) disk-service token that Active Storage puts in the Location header of the blob redirect, so the attacker knows the on-disk path of their own blob. The MSL script can therefore copy any readable file's bytes into that blob file, and the attacker downloads them through the ordinary blob URL — an arbitrary file read over HTTP. Overwriting any other writable path gives the arbitrary file write.
5. Trigger point. ActiveStorage::Attachment runs after_create_commit :analyze_blob_later, so analysis — and therefore the MSL execution — happens in the request that attaches the file. No variant, preview, or explicit analyze call is needed.

Fix commit: ea8c40121ce53a3d0255cd4eb6d13bfe3bc01776 ("Ship an ImageMagick security policy for every MiniMagick process", 8.0 branch; 8.1 branch 468aa9a93fc98f5476b6821770f4ccfcb7f7d328). The fix ships activestorage/lib/active_storage/image_magick/policy.xml and prepends its directory to MAGICK_CONFIGURE_PATH through MiniMagick.cli_env, so every ImageMagick process MiniMagick spawns denies MSL, the other file-reaching coders, the network coders, the Ghostscript coders/delegate, and @filename indirection. It also raises at boot for :mini_magick applications whose mini_magick is older than 5.1 (which cannot apply the policy) — a behaviour observed directly in this run when the fixed application was first started with mini_magick 5.0.1.

Reproduction Steps

1. bundle/repro/reproduction_steps.sh is the single entrypoint. It:
   • resolves the Rails repository from bundle/project_cache_context.json (<project_cache_dir>/repo), creates a worktree of the vulnerable commit (ea8c40121ce53a3d0255cd4eb6d13bfe3bc01776^, RAILS_VERSION 8.0.5.1) and of the fixed commit (ea8c40121ce53a3d0255cd4eb6d13bfe3bc01776), and asserts the patch is absent from the first and present in the second;
   • builds bundle/repro/docker/Dockerfile: ImageMagick 7.1.1-32 built from upstream source without librsvg (so the SVG coder uses ImageMagick's own internal renderer, exactly as in the reported chain) under the Debian/Ubuntu-style policy.xml (which does not deny MSL), plus two minimal but real Rails applications (/app-vuln, /app-fixed) that use activestorage from the two worktrees, variant_processor = :mini_magick, the Disk service, active_job.queue_adapter = :inline, mini_magick 5.0.x for the vulnerable app and mini_magick 5.1+ for the fixed app;
   • starts both applications under Puma with SECRET_KEY_BASE in the process environment, plants a credential file at /srv/pruva_credentials.txt, and runs bundle/repro/attack/attack.py twice against each application.
2. attack.py is a pure HTTP client. It fetches the upload form and its CSRF token, attaches four uploads through POST /uploads (an exfiltration blob, a second exfiltration blob, the attacker's payload bytes, and the MSL script), recovers each blob key by decoding the signed disk token in the blob redirect, attaches the SVG <image xlink:href="msl:<blob path>"> (which triggers the analyzer at attach time), retries the environment read with decreasing sizes, and then verifies the effects.
3. Expected evidence: on the vulnerable application the attacker's bytes appear at /tmp/pruva_arbitrary_write.txt, the attacker's own blob now carries the server's process environment (including SECRET_KEY_BASE) and the planted credential file, and a subsequent page request executes the template the MSL write replaced. On the fixed application nothing happens and the server log shows ImageMagick refusing the coder: attempt to perform an operation not allowed by the security policy 'MSL'.

Evidence

All paths are relative to bundle/.

Key excerpts (vulnerable application, attempt 1):

exfiltration channel on disk: /app-vuln/storage/fe/8k/fe8k0q5kmsjoxy2exjuo5r4a43t7
attached script_env1024.msl (1888 bytes, application/octet-stream) -> /uploads/3
delivering SVG env1024: <image xlink:href="msl:/app-vuln/storage/t3/c0/t3c0s3ff8jvzeagukdhys8grjfa1">
arbitrary write to /tmp/pruva_arbitrary_write.txt: matches attacker content
environment read with 64 samples (128 bytes) returned 1664 bytes
exfiltrated 1664 bytes through the attacker's own blob (SECRET_KEY_BASE present: True, planted credential recovered: True)
response after the template write contains command output: 'uid=0(root) gid=0(root) groups=0(root)'
server-side RCE marker file content: 'PRUVA_RCE_841517157f8b' (expected 'PRUVA_RCE_841517157f8b')

Exfiltrated environment (fragment, from logs/attempts/vuln_1/12_exfil_environ.txt):

HOSTNAME=32925638596e
RUBY_VERSION=3.4.12
PWD=/app-vuln
...
SECRET_KEY_BASE=04c5dd7e95...

Fixed application (both attempts):

exfiltrated 68 bytes through the attacker's own blob (SECRET_KEY_BASE present: False, planted credential recovered: False)
response after the template write contains command output: None
identify: attempt to perform an operation not allowed by the security policy `MSL' @ error/constitute.c/IsCoderAuthorized/454.

Environment: Linux x86_64, Docker 27.5.1, ruby:3.4-bookworm, Ruby 3.4.12, activestorage 8.0.5.1 (vulnerable worktree 7fe85a72a789eae5ee070ce3ee1dad10a8a5f70c) and the fix commit ea8c40121ce53a3d0255cd4eb6d13bfe3bc01776 for the control, mini_magick 5.0.1 / 5.4.0, ImageMagick 7.1.1-32 Q16-HDRI (source build, internal SVG renderer, Debian/Ubuntu-style policy.xml that does not deny MSL), Puma, SQLite, Active Storage Disk service.

Recommendations / Next Steps

• Apply the vendor fix: upgrade activestorage to 8.0.5.2 / 8.1.4.1 or later, which ships the ImageMagick policy and applies it through MiniMagick.cli_env; with :mini_magick, also upgrade mini_magick to 5.1 or later (older versions make the fixed release raise at boot, as observed here).
• Do not rely on the host policy alone. A host policy that denies MSL blocks the reported chain, but the advisory is explicit that it does not assume this is the only chain; the shipped policy is a denylist and the variant-analysis stage should test its completeness (coder aliases, host policy re-allow rules placed after the shipped one, GraphicsMagick, applications that replace MiniMagick.cli_env/cli_prefix or install their own MiniMagick::Shell).
• Constrain coders, not just files: prefer :vips for variant processing, and treat "attach" as an untrusted-input boundary — analysis must not run with privileges or file access beyond the blob.
• Run the app without write access to its own code and without reloading in production; that removes the demonstrated write→execution path but not the write or the read.
• Testing recommendation: keep a regression test that attaches a file whose content is <msl>-bearing SVG and asserts that no file named by the script is created.

Additional Notes

• Idempotency: the script is self-contained and was run twice consecutively; both runs ended with === reproduction confirmed === and exit status 0. Each attempt uses fresh random marker content, so the marker evidence cannot be satisfied by leftovers from an earlier run; the show template is restored from /app-src before every attempt.
• Limitations: (1) the RCE leg is conditional on the application loading the overwritten path (demonstrated with code reloading enabled; see Impact Parity); (2) ImageMagick is a source build of upstream 7.1.1-32 without librsvg, chosen because the Debian/Ubuntu packages of the same era carry additional hardening that refuses explicit coder prefixes inside SVG references, and because the reported chain relies on ImageMagick's own internal SVG renderer; the shipped Debian/Ubuntu-style policy (which does not deny MSL) is installed unchanged; (3) the environment read is attempted with progressively smaller raw sizes because ImageMagick aborts an MSL script when a raw read runs past the end of a regular file (the payload writes therefore run first); on this target the very first attempt returned the whole /proc/self/environ (1664 bytes, SECRET_KEY_BASE included) even though 128 bytes were requested, because procfs reports no size.