CVE-2022-35922: Memory allocation based on untrusted length in rust-websocket
Impact Untrusted websocket connections can cause an out-of-memory (OOM) process abort in a client or a server. The root cause of the issue is during dataframe parsing. Affected versions would allocate a buffer based on the declared dataframe size, which may come from an untrusted source. When Vec::withcapacity fails to allocate, the default Rust allocator will abort the current process, killing all threads. This affects only sync (non-Tokio) implementation. Async version also does not limit memory, but does not use withcapacity, so DoS can happen only when bytes for oversized dataframe or message actually got delivered by the attacker.
This is a security concern for you, if - your server application handles untrusted websocket connections - OR your client application connects to untrusted websocket servers
Patches The crashes are fixed in version 0.26.5 by imposing default dataframe size limits. Affected users are advised to update to this version.
Note that default memory limits are rather large (100MB dataframes and 200 MB messages), so they can still cause DoS in some environments (i.e. 32-bit). New API has been added to fine tune those limits for specific applications.
Workarounds
Migrate your project to another, maintained Websocket library like Tungstenite. Accept only trusted WebSocket traffic. Filter the WebSocket traffic though some kind of proxy that ensures sanity limits on messages. Handle process aborts gracefully and limit process memory using OS tools.
Credits This issue was reported by Evan Richter at ForAllSecure and found with Mayhem and Cargo Fuzz.
Other sources
Rust-WebSocket is a WebSocket (RFC6455) library written in Rust. In versions prior to 0.26.5 untrusted websocket connections can cause an out-of-memory (OOM) process abort in a client or a server. The root cause of the issue is during dataframe parsing. Affected versions would allocate a buffer based on the declared dataframe size, which may come from an untrusted source. When Vec::withcapacity fails to allocate, the default Rust allocator will abort the current process, killing all threads. This affects only sync (non-Tokio) implementation. Async version also does not limit memory, but does not use withcapacity, so DoS can happen only when bytes for oversized dataframe or message actually got delivered by the attacker. The crashes are fixed in version 0.26.5 by imposing default dataframe size limits. Affected users are advised to update to this version. Users unable to upgrade are advised to filter websocket traffic externally or to only accept trusted traffic.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service issue?
Server applications that accept untrusted WebSocket connections and client applications that connect to untrusted WebSocket servers are affected. The issue applies only to the synchronous, non-Tokio implementation.
What does an attacker need to do to trigger the synchronous implementation failure?
An attacker needs to provide a WebSocket dataframe with an untrusted declared size large enough to make the application attempt an allocation that fails. The default Rust allocator then aborts the process, terminating all threads.
Is the async implementation affected in the same way?
The async implementation does not use Vec::with_capacity and therefore does not abort based solely on a declared oversized dataframe length. It still lacks memory limits, so a denial of service is possible if the attacker actually delivers the bytes for an oversized dataframe or message.
What remediation is available, and are further configuration changes needed?
Update to version 0.26.5, which adds default dataframe size limits. The defaults allow 100 MB dataframes and 200 MB messages, so environments with tighter memory constraints, such as 32-bit systems, should use the new API to set lower limits.