CVE-2024-41128

What it actually does

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the query parameter filtering mechanism of Action Pack, a core component of Ruby on Rails. An attacker can send a web request with specially crafted query parameters that cause the regular expression engine to enter a state of catastrophic backtracking. This consumes excessive CPU resources, leading to a single worker process becoming unresponsive. By sending multiple such requests, an attacker can exhaust all available application server processes, resulting in a complete denial of service for the application.

Why it matters to the business

Exploitation of this vulnerability will render the affected web application or service completely unavailable to legitimate users. This can lead to operational disruption, customer dissatisfaction, potential revenue loss for e-commerce platforms, and damage to the organization's reputation. As Ruby on Rails is a widely used framework, the potential for impact is significant across many web applications. The vulnerability does not lead to data compromise, but the service outage can be severe.

How an attack unfolds

An unauthenticated, remote attacker first identifies a target application running a vulnerable version of Ruby on Rails on a Ruby interpreter older than version 3.2. The attacker then crafts a malicious HTTP request containing a query string with parameters designed to exploit the inefficient regular expression in the Action Dispatch filtering logic. Upon receiving the request, the Rails application attempts to process these parameters, triggering the ReDoS condition. The server's CPU usage for that worker process spikes to 100%, effectively freezing it. By repeating this process, the attacker can tie up all server resources, causing a denial of service.

How to fix it

The primary remediation is to upgrade the Ruby on Rails framework to a patched version. Depending on your current version, upgrade to one of the following or a later version: - Rails 6.1.x users should upgrade to 6.1.7.9. - Rails 7.0.x users should upgrade to 7.0.8.5. - Rails 7.1.x users should upgrade to 7.1.4.1. - Rails 7.2.x users should upgrade to 7.2.1.1. As a workaround or alternative mitigation, you can upgrade the underlying Ruby interpreter to version 3.2 or newer. Ruby 3.2 contains mitigations for this type of ReDoS vulnerability, rendering the application unaffected even with a vulnerable Rails version. For applications with downstream dependencies like Mattermost, ensure you upgrade to the version that incorporates the fix, such as 9.4.2 or newer for `mattermost-server`.

How to confirm the fix worked

To validate if your application is vulnerable, check the version of the `rails` gem specified in your `Gemfile.lock`. Compare this version against the fixed versions (6.1.7.9, 7.0.8.5, 7.1.4.1, 7.2.1.1). Additionally, check your Ruby interpreter version by running `ruby -v`. If the version is 3.2.0 or higher, you are not affected. To confirm the fix has been applied, ensure your `Gemfile.lock` reflects the patched `rails` version after running `bundle update rails` and redeploying your application.

Typical attack path

1. Attacker identifies a public-facing web application built with a vulnerable version of Ruby on Rails.
2. Attacker crafts an HTTP request with a malicious query string designed to trigger exponential backtracking in the regex engine during parameter filtering.
3. Attacker sends the crafted request to any endpoint on the vulnerable application.
4. The application's Action Dispatch component attempts to process the query parameters, leading to excessive CPU consumption and causing the worker process to hang.
5. By repeating the request, the attacker exhausts all application server processes, making the application unavailable to legitimate users.

How to detect it

To detect potential exploitation attempts, monitor web server access logs, application logs, and Application Performance Monitoring (APM) data. Look for a correlation between incoming HTTP requests with unusually long or complex query strings and periods of sustained, high CPU utilization (e.g., 90-100%) on application servers. APM tools may highlight specific transactions with abnormally long response times, where the time is spent within the application code rather than in database or external service calls. Application server logs may also show worker processes timing out or being automatically restarted by a master process.

What your security team should do

• Identify all applications using Ruby on Rails within your environment and determine their framework and Ruby interpreter versions.
• Prioritize patching for public-facing and business-critical applications to mitigate the risk of service disruption.
• Apply the recommended Rails version upgrade as the primary remediation path.
• If a Rails upgrade is not immediately possible, evaluate upgrading the Ruby interpreter to version 3.2+ as a strong compensating control.
• Configure monitoring and alerting for sustained high CPU usage on Rails application servers, which could indicate an active exploitation attempt.