CVE-2022-24795: Yajl-ruby Heap Corruption DoS Vulnerability

CVE-2022-24795 Overview

CVE-2022-24795 is an integer overflow vulnerability affecting yajl-ruby, a C binding to the YAJL JSON parsing and generation library. Both the 1.x and 2.x branches of yajl contain an integer overflow that leads to subsequent heap memory corruption when processing large inputs approaching 2GB in size. The vulnerability exists in the reallocation logic at yajl_buf.c#L64, where the need 32-bit integer can wrap to 0 when it approaches a value of 0x80000000 (~2GB of data). This results in a reallocation of buf->alloc into a small heap chunk, followed by population based on the original buffer size, leading to heap memory corruption.

Critical Impact

This vulnerability primarily impacts process availability through denial of service. While maintainers believe exploitation for arbitrary code execution is unlikely, the heap memory corruption could potentially lead to unpredictable application behavior.

Affected Products

• yajl-ruby 1.x branch (all versions prior to patch)
• yajl-ruby 2.x branch on 32-bit platforms
• Applications using yajl-ruby for JSON parsing with large input handling

Discovery Timeline

• April 5, 2022 - CVE-2022-24795 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-24795

Vulnerability Analysis

The vulnerability is classified as CWE-122 (Heap-based Buffer Overflow). The integer overflow occurs in the buffer reallocation logic within the YAJL library's C code. When processing JSON data approaching 2GB in size, the 32-bit integer used to track the required buffer size (need) wraps around to 0 due to integer overflow. This causes the memory allocator to allocate a much smaller buffer than actually required.

The 2.x branch of yajl declares these integers as size_t, which on 64-bit platforms would be a 64-bit integer, practically preventing the issue from triggering. However, on 32-bit builds where size_t is a 32-bit integer, the vulnerability remains exploitable. The subsequent write operations to the under-allocated heap chunk are based on the original (large) buffer size, resulting in heap memory corruption beyond the allocated boundaries.

Root Cause

The root cause is insufficient bounds checking on integer arithmetic in the buffer reallocation logic at yajl_buf.c#L64. When the need variable approaches 0x80000000 (approximately 2GB), the 32-bit integer wraps to 0 due to overflow, causing a minimal buffer allocation that is subsequently overwritten with data far exceeding its capacity.

Attack Vector

An attacker can exploit this vulnerability by sending specially crafted large JSON payloads (~2GB) to an application that uses yajl-ruby for JSON parsing. The attack can be conducted remotely over the network without authentication or user interaction. The primary impact is denial of service through application crash, though the heap memory corruption could potentially have broader security implications.

The security patches addressed multiple issues including depth validation:

         yajl_gen_invalid_number,
         /** A print callback was passed in, so there is no internal
          * buffer to get from */
-        yajl_gen_no_buf
+        yajl_gen_no_buf,
+        /** Tried to decrement at depth 0 */
+        yajl_depth_underflow
     } yajl_gen_status;

     /** an opaque handle to a generator */

Source: GitHub Commit

Additional depth checking improvements were implemented:

     if (++(g->depth) >= YAJL_MAX_DEPTH) return yajl_max_depth_exceeded;

 #define DECREMENT_DEPTH \
-    if (--(g->depth) >= YAJL_MAX_DEPTH) return yajl_gen_error;
+    if (--(g->depth) >= YAJL_MAX_DEPTH) return yajl_depth_underflow;

 #define APPENDED_ATOM \
     switch (g->state[g->depth]) {                   \

Source: GitHub Commit

Detection Methods for CVE-2022-24795

Indicators of Compromise

• Unusual application crashes or segmentation faults in processes using yajl-ruby
• Incoming JSON payloads with sizes approaching or exceeding 2GB
• Memory allocation failures followed by heap corruption indicators
• Abnormal process termination in Ruby applications handling JSON data

Detection Strategies

• Monitor for unusually large HTTP request bodies containing JSON content
• Implement application-level logging for JSON parsing operations and their input sizes
• Deploy memory protection mechanisms that can detect heap corruption attempts
• Use runtime application self-protection (RASP) to monitor buffer operations in yajl-ruby

Monitoring Recommendations

• Configure web application firewalls to block excessively large JSON payloads
• Implement request size limits at the application and infrastructure layers
• Monitor system memory usage patterns for anomalies indicating heap corruption
• Enable core dump analysis for post-incident forensics on affected systems

How to Mitigate CVE-2022-24795

Immediate Actions Required

• Update yajl-ruby to version 1.4.2 or later which contains the security patch
• Implement input size validation to reject JSON payloads approaching 2GB
• Review applications using yajl-ruby on 32-bit platforms as they are most susceptible
• Consider migrating 32-bit deployments to 64-bit platforms where size_t is 64-bit

Patch Information

A security patch is available in commit 7168bd79b888900aa94523301126f968a93eb3a6. This fix is anticipated to be part of yajl-ruby version 1.4.2. Organizations should update their yajl-ruby dependency to the patched version as soon as possible. For additional details, see the GitHub Security Advisory and distribution-specific advisories from Debian and Fedora.

Workarounds

• Avoid passing large inputs (approaching 2GB) to YAJL for JSON parsing
• Implement strict input size limits at the application boundary
• Use alternative JSON parsing libraries if large payload handling is required
• Deploy on 64-bit platforms where the vulnerability is practically mitigated

# Configuration example - Input size limit in nginx
client_max_body_size 100m;

# Ruby-level protection - Add size check before YAJL parsing
max_json_size = 100 * 1024 * 1024  # 100MB limit
if json_input.bytesize > max_json_size
  raise "JSON input exceeds maximum allowed size"
end