[ https://issues.apache.org/jira/browse/ZOOKEEPER-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825555#comment-17825555 ]
Trayan Simeonov commented on ZOOKEEPER-4776: -------------------------------------------- Is this going to be prioritized any time soon. It is an opened vulnerability which is being opened for 4 months now. It will be nice to have some update on this one. Thanks! > CVE-2023-36478 | org.eclipse.jetty_jetty-io > ------------------------------------------- > > Key: ZOOKEEPER-4776 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4776 > Project: ZooKeeper > Issue Type: Bug > Affects Versions: 3.9.1 > Reporter: Aayush Suri > Priority: Major > > {*}Vulnerability summary{*}: Eclipse Jetty provides a web server and servlet > container. In versions 11.0.0 through 11.0.15, 10.0.0 through 10.0.15, and > 9.0.0 through 9.4.52, an integer overflow in `MetaDataBuilder.checkSize` > allows for HTTP/2 HPACK header values to exceed their size limit. > `MetaDataBuilder.java` determines if a header name or value exceeds the size > limit, and throws an exception if the limit is exceeded. However, when length > is very large and huffman is true, the multiplication by 4 in line 295 will > overflow, and length will become negative. `(_size+length)` will now be > negative, and the check on line 296 will not be triggered. Furthermore, > `MetaDataBuilder.checkSize` allows for user-entered HPACK header value sizes > to be negative, potentially leading to a very large buffer allocation later > on when the user-entered size is multiplied by 2. This means that if a user > provides a negative length value (or, more precisely, a length value which, > when multiplied by the 4/3 fudge factor, is negative), and this length value > is a very large positive number when multiplied by 2, then the user can cause > a very large buffer to be allocated on the server. Users of HTTP/2 can be > impacted by a remote denial of service attack. The issue has been fixed in > versions 11.0.16, 10.0.16, and 9.4.53. There are no known workarounds. > Looking for a version the fixes this vulnerability. -- This message was sent by Atlassian Jira (v8.20.10#820010)