Netty HTTP Request Smuggling and RTSP Request Injection Vulnerability via URI Setter Bypass

A vulnerability in Netty's HTTP and RTSP request handling allows for request-line validation to be bypassed. This issue arises in 'DefaultHttpRequest' and 'DefaultFullHttpRequest' when the URI is changed using 'setUri()' after the request has been created. The constructors of these classes properly validate URIs by rejecting CRLF and whitespace characters that could disrupt the request line. However, the 'setUri()' method lacks this validation, enabling CRLF injection and the insertion of additional HTTP or RTSP requests. As a result, this vulnerability can lead to HTTP request smuggling, desynchronization in HTTP communications, and injection of requests in RTSP sessions.

Impact

Exploitation of this vulnerability allows for HTTP request smuggling, desynchronization of HTTP requests, and injection of RTSP requests. In the case of HTTP, it can confuse request boundaries, bypass authentication or routing assumptions, and disrupt proxy or backend server synchronization. The exact impact varies based on how URIs are constructed and how HTTP or RTSP components interpret request boundaries.

Reproduction

To reproduce this vulnerability, create a 'DefaultHttpRequest' or 'DefaultFullHttpHttpRequest' object with a valid URI. After the object is created, use 'setUri()' to inject a URI containing CRLF characters or additional request payloads. Then, serialize the request using 'HttpRequestEncoder' or 'RtspEncoder'. The injected CRLF characters will be interpreted as the start of a new request by the server or RTSP peer, demonstrating the bypassed validation and the resulting injection of additional requests.

Remediation

Users can upgrade to Netty versions 4.2.13.Final or 4.1.133.Final, where this vulnerability has been fixed.