CVE-2023-3223: Red Hat Undertow DoS Vulnerability

CVE-2023-3223 Overview

A memory exhaustion vulnerability has been identified in Red Hat Undertow, a high-performance web server used in JBoss middleware products. The flaw affects servlets annotated with @MultipartConfig, which can trigger an OutOfMemoryError when processing large multipart content. This vulnerability enables unauthorized remote attackers to cause a Denial of Service (DoS) condition against affected systems.

The vulnerability is particularly concerning because it allows attackers to bypass file size restrictions. When a server uses fileSizeThreshold to limit uploaded file sizes, attackers can circumvent this protection by setting the file name in the request to null, effectively rendering the size limit ineffective.

Critical Impact

Remote attackers can exhaust server memory and cause complete service disruption without authentication, affecting enterprise applications running on JBoss EAP, OpenShift Container Platform, and Red Hat Single Sign-On.

Affected Products

• Red Hat Undertow
• Red Hat OpenShift Container Platform (versions 4.9, 4.10, 4.11, 4.12)
• Red Hat OpenShift Container Platform for IBM LinuxONE (versions 4.9, 4.10)
• Red Hat OpenShift Container Platform for Power (versions 4.9, 4.10)
• Red Hat Enterprise Linux (versions 7.0, 8.0, 9.0)
• Red Hat JBoss Enterprise Application Platform 7.4
• Red Hat Single Sign-On 7.6

Discovery Timeline

• 2023-09-27 - CVE-2023-3223 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-3223

Vulnerability Analysis

This vulnerability falls under CWE-789 (Memory Allocation with Excessive Size Value), where the Undertow web server fails to properly limit memory allocation when handling multipart HTTP requests. The issue manifests in servlets that use the @MultipartConfig annotation for processing file uploads.

When a malicious request is crafted with excessively large multipart content, the server attempts to allocate memory to store the incoming data. Without proper bounds checking, this leads to memory exhaustion and subsequent OutOfMemoryError exceptions, crashing the application or making it unresponsive.

The bypass mechanism is especially noteworthy: the fileSizeThreshold parameter, designed to limit the size of files held in memory before being written to disk, can be evaded by manipulating the filename field in the multipart request. Setting this field to null causes the size validation logic to fail, allowing arbitrarily large content to be loaded into memory.

Root Cause

The root cause lies in insufficient validation of multipart request parameters within Undertow's request processing pipeline. The fileSizeThreshold validation logic contains a conditional check that fails when the filename is null, creating a bypass condition. Additionally, the server lacks adequate memory allocation limits when buffering multipart content, allowing unbounded memory consumption.

Attack Vector

The attack can be executed remotely over the network without any authentication requirements. An attacker sends a specially crafted HTTP multipart request to a vulnerable endpoint. The attack requires no user interaction and can be automated for sustained DoS attacks.

The attacker constructs a multipart/form-data request with:

1. An extremely large body to exhaust server memory
2. A null filename field to bypass fileSizeThreshold protections

When the vulnerable servlet processes this request, it attempts to buffer the entire content in memory. Multiple concurrent requests can rapidly deplete available heap space, causing the JVM to throw OutOfMemoryError and potentially crashing the entire application server.

Detection Methods for CVE-2023-3223

Indicators of Compromise

• Sudden spikes in JVM heap memory usage on application servers
• OutOfMemoryError exceptions in application logs with stack traces referencing multipart handling
• Unusual volume of large multipart POST requests to servlet endpoints
• Application server crashes or unresponsive states following multipart requests

Detection Strategies

• Monitor JVM heap usage and configure alerts for abnormal memory consumption patterns
• Implement web application firewall (WAF) rules to inspect and limit multipart request sizes at the network perimeter
• Review application logs for repeated OutOfMemoryError exceptions associated with multipart processing
• Deploy network-level monitoring to detect unusually large HTTP POST requests targeting known vulnerable endpoints

Monitoring Recommendations

• Configure JMX monitoring to track heap memory usage and garbage collection frequency on JBoss/Undertow servers
• Enable verbose garbage collection logging to identify memory pressure events
• Set up alerting for HTTP 500 errors that correlate with memory exhaustion events
• Monitor network traffic for large multipart requests exceeding expected business thresholds

How to Mitigate CVE-2023-3223

Immediate Actions Required

• Apply the latest security patches from Red Hat for all affected products
• Implement request size limits at the load balancer or reverse proxy level
• Configure web application firewall rules to block oversized multipart requests
• Review and harden @MultipartConfig annotations with explicit maxFileSize and maxRequestSize parameters

Patch Information

Red Hat has released multiple security advisories addressing this vulnerability:

• Red Hat Security Advisory RHSA-2023:4505
• Red Hat Security Advisory RHSA-2023:4506
• Red Hat Security Advisory RHSA-2023:4507
• Red Hat Security Advisory RHSA-2023:4509
• Red Hat Security Advisory RHSA-2023:4918
• Red Hat Security Advisory RHSA-2023:4919
• Red Hat Security Advisory RHSA-2023:4920
• Red Hat Security Advisory RHSA-2023:4921
• Red Hat Security Advisory RHSA-2023:4924
• Red Hat Security Advisory RHSA-2023:7247

For additional details, refer to the Red Hat CVE-2023-3223 Overview and Red Hat Bugzilla Report #2209689.

NetApp users should review NetApp Security Advisory NTAP-20231027-0004.

Workarounds

• Implement strict request size limits at the reverse proxy or load balancer layer before traffic reaches vulnerable applications
• Configure explicit maxFileSize and maxRequestSize parameters in @MultipartConfig annotations rather than relying solely on fileSizeThreshold
• Deploy rate limiting on endpoints that accept multipart uploads to mitigate automated attacks
• Consider implementing custom servlet filters to validate multipart request parameters before processing

# Example nginx configuration to limit request body size
# Add to server or location block to restrict upload sizes
client_max_body_size 10m;

# Example Apache configuration for request size limits
# Add to VirtualHost or Directory configuration
LimitRequestBody 10485760