Bugzilla – Bug 1145663
VUL-0: CVE-2019-9514: netty: HTTP/2 implementation is vulnerable to a reset flood, potentially leading to a denial of service
Last modified: 2022-04-14 13:51:07 UTC
CVE-2019-9514 Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-9514 http://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-9514.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514 http://www.cvedetails.com/cve/CVE-2019-9514/ https://seclists.org/bugtraq/2019/Aug/24 https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md https://kb.cert.org/vuls/id/605641/ https://lists.apache.org/thread.html/bde52309316ae798186d783a5e29f4ad1527f61c9219a289d0eee0a7@%3Cdev.trafficserver.apache.org%3E https://lists.apache.org/thread.html/ad3d01e767199c1aed8033bb6b3f5bf98c011c7c536f07a5d34b3c19@%3Cannounce.trafficserver.apache.org%3E https://lists.apache.org/thread.html/392108390cef48af647a2e47b7fd5380e050e35ae8d1aa2030254c04@%3Cusers.trafficserver.apache.org%3E
SUSE Manager exclusively uses netty because it is a dependency in pgjdbc-ng (a PostgreSQL Java driver), and no HTTP code from the library is used. Netty is only used to provide implementation of byte buffers/channels/sockets/NIO I/O in general. Does anything need to be done at all?
Another developer might later start to use the HTTP/2 functions of this package, or fork it to be used in another project, without being aware of the security implications. It would be preferable to have an updated version in all active repositories, in order to prevent future issues. netty version 4.1.39 fixes this and related CVEs. https://netty.io/news/2019/08/13/4-1-39-Final.html >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
At this point we have very little insight on the inner workings of pgjdbc-ng, so I would not feel confident about such a change until upstream pgjdbc-ng is updated and its author approves and tests such a change. As of the latest released pgjdbc-ng version 4.1.32.Final is required: https://github.com/impossibl/pgjdbc-ng/blob/v0.8.2/buildSrc/src/main/kotlin/Versions.kt#L14 And the same is true for the tip of the develop branch: https://github.com/impossibl/pgjdbc-ng/blob/239d492d1b244974b7c6356f5fee329839087989/buildSrc/src/main/kotlin/Versions.kt#L14 Changing the dependency downstream potentially invalidates all upstream and community testing and this represents a risk I would not suggest we run. Reason is this library is vital in SUSE Manager/Uyuni, as each and every Salt event goes though it. I opened a PR at pgjdbc-ng and suggest reacting only after it is merged and a new version is released. https://github.com/impossibl/pgjdbc-ng/pull/426
PR was merged, now waiting for the finalization of a new version.
I submitted requests to update our netty package to 4.1.14 which fixes this vulnerability, and Uyuni patches to adapt to the new version. https://github.com/uyuni-project/uyuni/pull/1877 https://build.opensuse.org/request/show/772129 https://build.opensuse.org/request/show/772127 https://build.suse.de/request/show/210975 https://build.suse.de/request/show/210973 https://build.suse.de/request/show/210972 https://build.suse.de/request/show/210970 This fix will be part of the next SUSE Manager major version, 4.1, as well. Can this bug just be closed to RESOLVED?
(In reply to Silvio Moioli from comment #7) > I submitted requests to update our netty package to 4.1.14 Typo, that was 4.1.44. This CVE number was fixed as of 4.1.39 according to: https://netty.io/news/2019/08/13/4-1-39-Final.html
Done.