CVE-2023-34462

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap. The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates a ByteBuf using the value defined in the ClientHello record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler. This vulnerability has been fixed in version 4.1.94.Final.

Summary

The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap.

Details

The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates a ByteBuf using the value defined in the ClientHello record.

Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler

1/ allocate a 16MB ByteBuf 2/ not fail decode method in buffer 3/ get out of the loop without an exception

The combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection.

Impact

If the user has no idle timeout handler configured it might be possible for a remote peer to send a client hello packet which lead the server to buffer up to 16MB of data per connection. This could lead to a OutOfMemoryError and so result in a DDOS.

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap. The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates a ByteBuf using the value defined in the ClientHello record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler. This vulnerability has been fixed in version 4.1.94.Final.

TuxCare rebuilt 43 io.netty packages to address 12 CVEs. Fixed in 4.1.63.Final-tuxcare.2.

TuxCare rebuilt 40 io.netty packages to address 9 CVEs. Fixed in 4.1.49.Final-tuxcare.1.

TuxCare rebuilt 6 io.netty packages to address 9 CVEs. Fixed in 4.1.58.Final-tuxcare.1.

TuxCare rebuilt 43 io.netty packages to address 15 CVEs. Fixed in 4.1.60.Final-tuxcare.1.

TuxCare rebuilt 46 io.netty packages to address 9 CVEs. Fixed in 4.1.75.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 12 CVEs. Fixed in 4.1.93.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 7 CVEs. Fixed in 4.1.92.Final-tuxcare.1.

TuxCare rebuilt io.netty:netty-handler to address 1 CVE. Fixed in 4.1.52.Final-tuxcare.2.

TuxCare rebuilt 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

TuxCare rebuilt 6 io.netty packages to address 7 CVEs. Fixed in 4.1.82.Final-tuxcare.8.

TuxCare rebuilt 46 io.netty packages to address 19 CVEs. Fixed in 4.1.80.Final-tuxcare.1.

TuxCare rebuilt 40 io.netty packages to address 26 CVEs. Fixed in 4.1.53.Final-tuxcare.1.

TuxCare rebuilt 11 io.netty packages to address 21 CVEs. Fixed in 4.1.51.Final-tuxcare.1.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.43.Final-tuxcare.3.

TuxCare rebuilt 5 io.netty packages to address 6 CVEs. Fixed in 4.1.48.Final-tuxcare.5.

TuxCare rebuilt 13 io.netty packages to address 24 CVEs. Fixed in 4.1.74.Final-tuxcare.1.

TuxCare rebuilt 5 io.netty packages to address 6 CVEs. Fixed in 4.1.72.Final-tuxcare.2.

TuxCare rebuilt 6 io.netty packages to address 7 CVEs. Fixed in 4.1.87.Final-tuxcare.4.

TuxCare rebuilt 4 io.netty packages to address 8 CVEs. Fixed in 4.1.68.Final-tuxcare.2.

These are all security issues fixed in the netty-4.1.114-1.1 package on the GA media of openSUSE Tumbleweed.

This update for netty, netty-tcnative fixes the following issues:

Upgrade to upstream version 4.1.94:

• CVE-2023-34462: Allow to limit the maximum lenght of the ClientHello (bsc#1212637).

It was discovered that Netty did not properly sanitize its input parameters. A remote attacker could possibly use this issue to cause a crash. (CVE-2023-34462)

It was discovered that Netty incorrectly handled request cancellation. A remote attacker could possibly use this issue to cause Netty to consume resources, leading to a denial of service. (CVE-2023-44487)