Ruby on Rails Active Storage Image Path Exposes File Write and Read Risks

En bref

• Rails apps using Active Storage and ImageMagick are exposed.
• Crafted image uploads can lead to unauthorized file creation or overwrite.
• Intruders may also access sensitive files and pivot to other hosts.
• No CVE identifier is associated with this issue.
• Prioritize inventory, mitigation, and monitoring on internet-facing servers.

A security weakness in how Ruby on Rails handles Active Storage uploads processed by ImageMagick is drawing attention because it gives threat actors a path to manipulate files on affected systems. The issue is not tied to a published CVE, so teams cannot rely on a scanner signature or advisory identifier to find it.

Applications that accept user-supplied images and pass them through ImageMagick are the primary concern. By submitting specially crafted image content, an adversary could cause the server to create or overwrite files in locations it should not reach. The same primitive may allow reading files that contain secrets or configuration data.

The blast radius extends beyond a single application process. Once an intruder can write and read files, they can use that foothold to inspect credentials, alter application behavior, or jump to other hosts reachable from the compromised server. That makes lateral movement a realistic follow-on risk, especially where Rails servers share networks or trust relationships with internal systems.

Because no CVE is listed, asset owners should treat this as a configuration and code-path review problem rather than waiting for a patch identifier. Inventory Rails services that use Active Storage with ImageMagick, restrict upload processing, and monitor for unexpected file changes. Watch for vendor guidance, community patches, and signs of suspicious image uploads in logs.

À faire maintenant

1. Inventory every Rails application that uses Active Storage with ImageMagick, prioritizing internet-facing and high-trust servers.
2. Apply current Rails and ImageMagick updates plus any vendor mitigations; if no fix is available, disable image processing or restrict accepted formats.
3. Enforce strict upload validation: allowlist image types, re-encode images in a sandboxed low-privilege service, and cap file sizes.
4. Run application and image-processing components with least privilege, use read-only filesystems where possible, and separate upload handling from sensitive data.
5. Monitor logs for anomalous uploads, unexpected file creation, and access to sensitive paths; alert on new files in web-accessible directories.
6. Segment networks and restrict outbound access from Rails hosts to limit lateral movement; rotate secrets if suspicious activity appears.
7. If compromise is suspected, isolate the host, preserve logs, and hunt for persistence and credential access.

Source originale

Dark Reading