Impact
The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.
An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.
The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.
The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.
Patches
This was released in nats-server without being highlighted as a security issue. It should have been, this was an oversight. Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.
This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.
Workarounds
This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.
References
This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).
References
Impact
The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.
An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.
The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.
The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.
Patches
This was released in nats-server without being highlighted as a security issue. It should have been, this was an oversight. Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.
This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.
Workarounds
This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.
References
This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).
References