How to remediate – Rails Unsafe Reflection

1. Introduction

Rails Unsafe Reflection is a vulnerability in Ruby on Rails applications where dynamic class instantiation via the `constantize` method can be exploited with user-supplied input. This allows attackers to potentially execute arbitrary code, leading to a complete compromise of the application. Systems using older versions of Ruby on Rails are most affected. A successful exploit could result in loss of confidentiality, integrity and availability of data.

2. Technical Explanation

The root cause is that Ruby On Rails’ `constantize` method dynamically finds classes based on string input without sufficient validation. An attacker can supply a malicious string to this method, causing the application to instantiate an unintended class and potentially execute code within its context. The vulnerability requires the application to directly use user-controlled strings in calls to `constantize`.

• Root cause: Lack of input validation on strings passed to the `constantize` method.
• Exploit mechanism: An attacker provides a crafted string as input, which is then used by `constantize` to load and instantiate an arbitrary class. For example, if user input controls a class name that’s later loaded with `constantize`, it can be manipulated to execute system commands.
• Scope: Ruby on Rails applications are affected. Specific versions should be checked against known vulnerabilities.

3. Detection and Assessment

Confirming vulnerability requires identifying uses of the `constantize` method within the application’s code base, particularly where user input is involved. A thorough review of code is needed to identify all potential entry points for exploitation.

• Quick checks: Search the codebase for instances of `constantize`.
• Scanning: Static Application Security Testing (SAST) tools can be used to identify calls to `constantize` with user-supplied input. Example tools include Brakeman and SonarQube, configured with appropriate rulesets.
• Logs and evidence: Look for unusual class instantiation errors or unexpected behaviour in application logs that might indicate an attempt to exploit the vulnerability.

grep -r "constantize" .

4. Solution / Remediation Steps

The solution is to avoid using user-supplied strings directly with the `constantize` method. Only trust known, safe strings for class instantiation. Implement strict input validation and sanitisation where necessary.

4.1 Preparation

• No services need to be stopped directly, but testing should be done in a non-production environment first.
• Roll back plan: Revert the code changes made during implementation.

4.2 Implementation

1. Step 1: Identify all instances of `constantize` used with user input.
2. Step 2: Replace direct use of user input with a whitelist of allowed class names or constants.
3. Step 3: If dynamic loading is unavoidable, implement strict validation to ensure the input matches an expected pattern and corresponds to a safe class name.

4.3 Config or Code Example

Before

Class.constantize(user_supplied_string)

After

allowed_classes = ['MySafeClass', 'AnotherSafeClass']
if allowed_classes.include?(user_supplied_string)
  Class.constantize(user_supplied_string)
else
  # Handle invalid input, e.g., raise an error or log the attempt
end

4.4 Security Practices Relevant to This Vulnerability

Input validation is key to preventing this issue. Least privilege can limit the impact if exploitation occurs. Safe defaults and regular patching are also important for overall security posture.

• Practice 2: Least Privilege – Run the application with the minimum necessary privileges to reduce the impact of a successful exploit.

4.5 Automation (Optional)

Automated code scanning tools can be integrated into CI/CD pipelines to detect uses of `constantize` with user input during development.

# Example using Brakeman in a CI pipeline:
brakeman -q --file app.rb --output html > brakeman_report.html

5. Verification / Validation

Confirm the fix by verifying that user input can no longer control the class name passed to `constantize`. Re-run any earlier detection methods to ensure they no longer identify the vulnerability. Test key application functionality to confirm it remains operational.

• Post-fix check: Attempt to pass a malicious string as input and verify that an error is raised or the attempt is logged, preventing class instantiation.
• Re-test: Re-run the `grep` command from step 3 of Detection and Assessment; it should no longer find vulnerable code patterns.
• Smoke test: Ensure core application features that previously used `constantize` still function as expected.
• Monitoring: Monitor application logs for any errors related to class instantiation or unexpected behaviour.

# Example attempt to exploit after fix (should fail):
Class.constantize("System") # Expect an error

6. Preventive Measures and Monitoring

Update security baselines to include rules against using `constantize` with user input. Implement SAST checks in CI/CD pipelines to catch similar vulnerabilities during development. Maintain a regular patch cycle for Ruby on Rails and its dependencies.

• Baselines: Include a rule in your application security baseline prohibiting the use of `constantize` with untrusted input.
• Pipelines: Integrate SAST tools into your CI/CD pipeline to automatically scan code for potential vulnerabilities, including unsafe uses of reflection.
• Asset and patch process: Implement a regular patch cycle for Ruby on Rails and its dependencies to address known security issues promptly.

7. Risks, Side Effects, and Roll Back

Changes may introduce regressions if dynamic class loading is essential. Thorough testing is crucial. If issues arise, roll back the code changes made during implementation.

• Risk or side effect 2: Incorrect validation rules could block legitimate use cases. Mitigation: Carefully define allowed classes and constants based on application requirements.
• Roll back: Revert the code changes made during implementation to restore the previous functionality.

8. References and Resources

• Vendor advisory or bulletin: https://blog.convisoappsec.com/en/exploiting-unsafe-reflection-in-rubyrails-applications/
• NVD or CVE entry: Not applicable (no specific CVE listed in context)
• Product or platform documentation relevant to the fix: Rails Security Guide