Rails Apps Arbitrary File Write Vulnerability Let Attackers Execute Code Remotely

   January 23, 2025  Posted in GBHackers


A newly exposed vulnerability in Ruby on Rails applications allows attackers to achieve Remote Code Execution (RCE) through a flaw that permits arbitrary file writing.

This vulnerability, which leverages the Rails library Bootsnap, underscores the critical importance of secure file handling in web applications.

What Happened?

A case study, shared by security researchers, demonstrated how an arbitrary file write vulnerability in a Rails app could be exploited to execute malicious code remotely.

The vulnerability arises from improper handling of uploaded files in a sample Rails endpoint, combined with the exploitation of Bootsnap, a library designed to speed up application boot times by caching expensive file operations.

Investigate Real-World Malicious Links & Phishing Attacks With Threat Intelligence Lookup - Try for Free

The demonstration rested on a vulnerable section of code where uploaded files could be saved to unrestricted paths using user-provided inputs:

def save_uploaded_file(uploaded_file, filename)

    upload_path = Rails.root.join("tmp", "uploads")

    FileUtils.mkdir_p(upload_path)

    File.open(File.join(upload_path, filename), 'wb') do |file|

        file.write(uploaded_file.read)

    end

end

Attackers exploited this by writing files to any writable directory, bypassing restrictions using path traversal techniques.

How Bootsnap and Arbitrary File Write Collide

Bootsnap, introduced to Rails in version 5.2, caches Ruby files, YAML, and JSON resources for faster load times.

By manipulating the cache files located in tmp/cache/bootsnap, attackers can inject malicious code to execute during application startup.

The exploit requires precise knowledge of the Bootsnap cache structure and the ability to restart the Rails application. Here’s how the attack works:

  1. Identify Writable Directories: Applications deployed in Docker containers might restrict writable locations to directories like /tmp or /rails/tmp.
  2. Target a Bootsnap Cache File: Bootsnap caches compiled Ruby bytecode in a predictable structure, keyed by a hash of the file path. This makes it easy to locate and overwrite the correct cache file using the arbitrary file write vulnerability.
  3. Inject Malicious Content: The attacker crafts a payload that includes malicious Ruby code and writes it into the appropriate cache file. For example, the payload could look like this:
`id > >&2`  # Command injection to print the current user

load("/path/to/original/file")  # Load the intended file to avoid crashing the app
  1. Trigger a Server Restart: Writing to tmp/restart.txt triggers a restart in Puma, the Rails application server.
  2. Achieve RCE: During startup, the malicious Bootsnap cache file is loaded, allowing the Ruby code to execute.

While the vulnerability requires specific conditions—like controllable file uploads and the use of Bootsnap in the Rails app—it poses a significant risk in production environments where these conditions are met.

According to researchers, default Rails Docker configurations after version 7.1 exacerbate the issue by limiting writable paths to a few key directories such as tmp and log.

  1. White-Box Exploitation: With full access to the application, exploiting the vulnerability is straightforward, as all information for crafting malicious cache keys is accessible.
  2. Black-Box Exploitation: Even in limited environments, brute-forcing values like file paths, Ruby versions, and cache formats remain feasible for attackers with sufficient resources.
  1. Secure File Handling: Validate and sanitize user inputs related to file uploads to prevent path traversal attacks.
  2. Restrict Writable Directories: Avoid granting broad write permissions in production. Use mechanisms like mandatory access controls to scope file-writing abilities to non-critical paths.
  3. Monitor and Patch: Regularly update dependencies like Bootsnap and Rails to remain protected against known vulnerabilities.
  4. Use Non-Root Users: As a best practice in Docker deployments, ensure containers run with non-root users to minimize potential damage.

As per a report by Conviso report, the “Rails Apps Arbitrary File Write Vulnerability Let Attackers Execute Code Remotely” highlights the dangers of combining insecure coding practices with existing libraries.

Developers and system administrators must work together to audit application code and configurations regularly, ensuring vulnerabilities like these are identified and mitigated before being exploited in the wild.

Integrating Application Security into Your CI/CD Workflows Using Jenkins & Jira -> Free Webinar



Source link