CVE-2022-24713: Rust-lang Regex DoS Vulnerability

CVE-2022-24713 Overview

CVE-2022-24713 is a denial of service vulnerability in the Rust regex crate, an implementation of regular expressions for the Rust programming language. The regex crate features built-in mitigations designed to prevent denial of service attacks caused by untrusted regexes or untrusted input matched by trusted regexes. However, a bug was discovered in these mitigations that allows attackers to craft specially designed regexes that bypass the protective measures, enabling denial of service attacks against services that accept user-controlled regular expressions.

Critical Impact

Services accepting user-controlled regexes are vulnerable to denial of service attacks through specially crafted regex patterns that bypass built-in mitigations, causing excessive parsing time and resource exhaustion.

Affected Products

• rust-lang regex (versions ≤ 1.5.4)
• Fedora 34, 35, and 36
• Debian Linux 9.0, 10.0, and 11.0

Discovery Timeline

• 2022-03-08 - CVE-2022-24713 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-24713

Vulnerability Analysis

This vulnerability exploits a flaw in the regex crate's denial of service mitigations. The regex crate was designed with tunable mitigations that provide sane defaults to prevent attacks from untrusted regexes taking arbitrary amounts of time during parsing. This guarantee was documented as part of the crate's API. However, a bug in the mitigation logic allows attackers to construct regex patterns that circumvent these protections entirely.

The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-1333 (Inefficient Regular Expression Complexity). The attack can be performed remotely without authentication, making any service that accepts user-controlled regex patterns a potential target.

Root Cause

The root cause lies in how the regex compiler tracks memory allocation during compilation. Specifically, empty sub-expressions did not properly contribute to the tracked heap memory usage, which is an implementation detail. Without proper accounting for empty sub-expressions, excessively large repetitions on empty sub-expressions could cause the compiler to consume excessive CPU time without triggering the size limit restrictions that would normally cause compilation to bail out.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker can send specially crafted regex patterns to any service that accepts user-controlled regular expressions. Because there are practically infinite regex patterns that could exploit this vulnerability, it is not possible to maintain a fixed set of problematic patterns to block.

// Security patch in src/compile.rs - security: fix denial-of-service bug in compiler
     suffix_cache: SuffixCache,
     utf8_seqs: Option<Utf8Sequences>,
     byte_classes: ByteClassSet,
+    // This keeps track of extra bytes allocated while compiling the regex
+    // program. Currently, this corresponds to two things. First is the heap
+    // memory allocated by Unicode character classes ('InstRanges'). Second is
+    // a "fake" amount of memory used by empty sub-expressions, so that enough
+    // empty sub-expressions will ultimately trigger the compiler to bail
+    // because of a size limit restriction. (That empty sub-expressions don't
+    // add to heap memory usage is more-or-less an implementation detail.) In
+    // the second case, if we don't bail, then an excessively large repetition
+    // on an empty sub-expression can result in the compiler using a very large
+    // amount of CPU time.
     extra_inst_bytes: usize,
 }

Source: GitHub Regex Commit

Detection Methods for CVE-2022-24713

Indicators of Compromise

• Unusual CPU spikes on services that process user-supplied regular expressions
• Extended response times or timeouts on regex compilation operations
• Application hangs or unresponsiveness when processing regex patterns
• Log entries indicating regex compilation failures or timeouts

Detection Strategies

• Monitor CPU utilization on services that accept user-controlled regex patterns for abnormal spikes
• Implement application-level logging for regex compilation times and flag patterns that exceed expected thresholds
• Use dependency scanning tools to identify vulnerable versions of the regex crate (≤ 1.5.4) in your Rust applications

Monitoring Recommendations

• Set up alerts for sustained high CPU usage on services processing user input
• Monitor application response times and establish baselines for regex operations
• Implement timeout mechanisms for regex compilation and pattern matching operations
• Review dependency audit reports regularly for known vulnerable packages

How to Mitigate CVE-2022-24713

Immediate Actions Required

• Upgrade the regex crate to version 1.5.5 or later immediately
• Audit all Rust applications that accept user-controlled regex patterns
• Apply operating system vendor patches for Fedora and Debian systems
• Consider implementing additional input validation or regex complexity limits at the application layer

Patch Information

The fix is included starting from regex version 1.5.5. The patch addresses the issue by tracking "fake" memory allocation for empty sub-expressions, ensuring that excessively large repetitions on empty patterns will properly trigger the compiler's size limit restrictions and bail out before consuming excessive CPU time.

Vendor patches are available:

• Rust-lang Security Announcement
• GitHub Security Advisory
• Debian Security Advisory DSA-5113
• Debian Security Advisory DSA-5118
• Gentoo GLSA 202208-08

Workarounds

• Avoid accepting user-controlled regular expressions if possible; use predefined patterns instead
• Implement strict timeout limits on regex compilation and matching operations
• Deploy rate limiting on endpoints that accept regex patterns to reduce attack surface
• Consider using alternative regex validation approaches that do not expose the full regex compilation pipeline to untrusted input

# Update the regex crate in Cargo.toml
# Ensure minimum version 1.5.5
cargo update -p regex

# Verify the installed version
cargo tree -i regex