Document Netty CVE's impact on Solr#206
Conversation
dsmiley
left a comment
dsmiley
left a comment
There was a problem hiding this comment.
See my comments for some concerns.
Rant:
I've never seen a project with so many vulnerabilities as Netty. I've seen this over years. I want us to stop shipping Netty altogether.
It's not necessary to include netty on the OTEL side. If someone wants to risk vulnerabilities then they are welcome to drop in the JARS to accomplish that goal.
The ZK side is annoying and I've invested time in pursuing ZK severing its trivial Netty dependency that it shouldn't have ever had. https://issues.apache.org/jira/browse/ZOOKEEPER-4835 witch my PR.
| `setUri()` can inject CRLF sequences and smuggle a second request. It affects Netty versions before | ||
| 4.1.133.Final and 4.2.0.Alpha1–4.2.12.Final; it is fixed in 4.1.133.Final and 4.2.13.Final. | ||
|
|
||
| Solr first started shipping Netty as a transitive dependency in **9.2.0** (SOLR-16532), when the |
There was a problem hiding this comment.
The narrative here speaks of Netty in an unqualified way, thus I'm thinking of any and all of Netty. Solr has shipped Netty (in whole or part) for much longer prior to 9.2.
There was a problem hiding this comment.
fair enough... I'm still trying to get a sense of how much "explanation" to provide, and I will try and prune it back to more specifics.
|
|
||
| Solr first started shipping Netty as a transitive dependency in **9.2.0** (SOLR-16532), when the | ||
| optional `opentelemetry` module was added; Solr versions before 9.2.0 don't include that module and | ||
| never carry Netty at all. Every release since 9.2.0 has pinned a vulnerable Netty: 4.1.114.Final |
There was a problem hiding this comment.
ever carry Netty at all
Jeesh that is so false.
| only pulls in `netty-transport-native-unix-common`, never the Epoll transport. It's a transitive dependency of **Apache ZooKeeper**'s client library | ||
| (`org.apache.zookeeper:zookeeper`), which optionally supports a Netty-based connection socket for | ||
| both its client and server roles. Solr is **not affected**: |
There was a problem hiding this comment.
correct...
Note: if someone chooses to use a SSL/TLS based ZooKeeper connections and follows ZooKeeper instructions to do so, then Netty will be used.
There was a problem hiding this comment.
So, is this statement "solr not affected" correct, except that if someone choooses " to use a SSL/TLS based ZooKeeper connections and follows ZooKeeper instructions to do so, then Netty will be used."? I am looking more into the code to see if that is the case... i.e, i fyou configure zk that way, does it all work in solr.
There was a problem hiding this comment.
okay, digging in more, you can use ssl zk with solr, but it's a not default setup... updating statements. i've never done it, so didn't think oabut it...
|
|
||
| Solr has shipped a vulnerable `netty-handler-proxy` since Netty first became a transitive | ||
| dependency in 9.2.0 (4.1.x through the 9.2.0–9.9.0 line, 4.2.x — `netty-handler-proxy-4.2.6.Final.jar` | ||
| — from 9.10.0/10.0.0 onward); Solr versions before 9.2.0 don't ship Netty at all. This artifact |
There was a problem hiding this comment.
don't ship Netty at all
Again, a totally false statement. I won't repeat this claim but I bet it repeats.
There was a problem hiding this comment.
When a dependency comes transitively via OTEL (a major subsystem, popular project), I hope one day we can instead have transitive VEX statements instead of having to explain why the dependencies of our dependencies of our dependencies are not vulnerable.
There was a problem hiding this comment.
Yeah... I'm still feeling my way around VEX, and honestly, I think we, Solr, are early guinea pigs of shipping these files.... Also, looking back at soem of the original emails, there definitly is discussion about automated tooling that identifies these things.
2 participants
Solr is being flagged as having many Netty CVE's, but it turns out they are not applicable to Solr based on how we use Netty.
This PR documents the reason why.