[
https://issues.apache.org/jira/browse/ZOOKEEPER-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089529#comment-18089529
]
Diego Rivera commented on ZOOKEEPER-5038:
-----------------------------------------
Hi, all!
I have no idea if this has been considered and discarded already, but has
anyone considered a third approach by way of a [multi-release
JAR|https://www.baeldung.com/java-multi-release-jar] where if one is using JDK
17, the JVM uses the classes that bind to the updated Jetty 12+ stuff, vs.
people using the older JDKs (8, 11) can stick with the older, vulnerable stuff?
The `zkServer.sh` (et al) script(s) could be adjusted to detect the JVM version
early, and set up the classpath using alternate supplementary directories that
would include the appropriate Jetty stuff (i.e. `${zkHome}/lib-17` vs.
`${zkHome}/lib-8` or whatever). Thus, the classpath could end up being
something like `${zkHome}/lib-XX:${zkHome}/lib:....`
The multi-release JARs would live in `${zkHome}/lib`, and the "supplementary"
sets of JARs (i.e. Jetty 9 or Jetty 12) would each live in
`${zkHome}/lib-${JDK_VER}` ... you could go with only two values for
`${JDK_VER}`: `17` for all JDKs >= 17, and `8` for all others:
- `${zkHome}/lib-17` contains the latest Jetty 12+ stuff, and is only
"activated" when the launch scripts identify that you're using Java 17+
- `${zkHome}/lib-8` contains the old, outdated, never-to-be-fixed Jetty 9
stuff, and is activated for all Java versions prior to 17
- `${zkHome}/lib` contains all the common-use stuff that would be used
regardless of which JVM is in use (any multi-release JARs would be stored here)
This might prove to be much less risky since you'd be leaving the older classes
intact for people who are willing to accept the risk from the vulnerability
without accruing additional risk from modifications, while being able to add
the modified classes (i.e. the new classes using `jakarta.*`, etc., as
described above) for use by everyone else.
This would at least provide relief for those of us facing issues to do that
vulnerability coming up in security reports (i.e. for compliance reasons), and
should be less labor intensive and less risky than either of the above
scenarios.
Is this even a possiblity?
Cheers!
> Upgrade Jetty to address CVE-2026-2332
> --------------------------------------
>
> Key: ZOOKEEPER-5038
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5038
> Project: ZooKeeper
> Issue Type: Task
> Components: server
> Affects Versions: 3.9.5, 3.8.6
> Reporter: Jota Martos
> Assignee: Dávid Paksy
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Jetty versions lower than 9.4.60 are affected by this CVE.
> bq. Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer
> encoding extension values, enabling request smuggling attacks.
> You can find more information in the [security
> advisory|https://github.com/jetty/jetty.project/security/advisories/GHSA-355h-qmc2-wpwf].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
