Skip navigation

Netty 4.1.39.Final released

by normanmaurer
on

I am happy to announce the release of netty 4.1.39.Final. This is a bug-fix release but also contains a few performance enhancements. Most importantly it fixed multiple HTTP/2 security issues, for more details see the section below.

The most important changes in this release are:

  • HTTP2: Guard against empty DATA frames (without end_of_stream flag) set (#9461)
  • HTTP2: Add protection against remote control frames that are triggered by a remote peer (#9460)
  • Set the ORIGIN header from a custom headers if present (#9435)
  • Do not cache local/remote address when creating EpollDatagramChannel with InternetProtocolFamily (#9436)
  • Fix HttpUtil.getCharset to not throw IllegalCharsetNameException (#9439)

For the details and all changes, please browse our issue tracker for 4.1.39.Final.

HTTP/2 Security issues

Multiple servers / libraries that contain a HTTP/2 implementations have been discovered to be affected by multiple DOS attacks, if the user itself does not provide special handlers for protection. Netty's HTTP/2 implementation is affected by the vulnerabilities as listed below:

  • CVE-2019-9512: Ping Flood
  • CVE-2019-9514: Reset Flood
  • CVE-2019-9515: Settings Flood
  • CVE-2019-9518: Empty DATA frame flooding

For more details please read the full report by Netflix

Ping Flood, Reset Flood, Settings Flood (CVE-2019-9512, CVE-2019-9514, CVE-2019-9515)

A Netty based HTTP/2 server can be forced to buffer unbounded amounts of memory when flooded with control frames that require an automatic response.

This attack is addressed by Netty by counting the number of outstanding control frames that needs to be written and if a limit is hit closing the connection. The limit is configurable to allow more flexibility and lower the risk of false-positives.

Empty DATA frame flooding (CVE-2019-9518)

A Netty based HTTP/2 server could be forced to consume substantial CPU resources by sending it an unbounded sequence of empty DATA frames that do not have END_STREAM set on them.

This attack was addressed by Netty by counting the number of empty DATA frames without the END_STREAM flag set, and if such an attach is detected closing the connection.

Thank You

Every idea and bug-report counts and so we thought it is worth mentioning those who helped in this area. Please report an unintended omission.