https://issues.apache.org/jira/browse/SOLR-16568 is merged and upgrades woodstox-core. The only woodstox-core CVE that remained is CVE-2022-40152 ( https://github.com/advisories/GHSA-3f7h-mf4q-vrm4) and fixed in https://github.com/FasterXML/woodstox/issues/160. It is LOW severity only.
Kevin Risden On Sat, Dec 3, 2022 at 1:10 PM Gus Heck <gus.h...@gmail.com> wrote: > Hi Billy, > > Thanks for bringing this up. The CVE you link is rejected ( > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40153). However > reading through the report here: > https://github.com/x-stream/xstream/issues/304 it seems that this was part > of a series of low quality auto generated CVE reports and 4/6 of them were > rejected, but annoyingly NVD only reflects the rejected status for 3 out of > 4, having missed it for the one you linked. In any case, > https://nvd.nist.gov/vuln/detail/CVE-2022-40152 did eventually stick to > woodstox after initially being reported against x-stream and can be fixed > by an upgrade to woodstox 6.4. Main branch is on 6.3.1 presently and Solr > will receive this upgrade to 6.4 as part of the Caffeine Cache upgrade, so > you can follow https://issues.apache.org/jira/browse/SOLR-16562 (I have > added a comment so, hopefully it at least shows up in searches for the > correct CVE soon). > > Sorry the response took so long, For my part I missed the first mail you > sent. It's not my job any more than anyone else on the PMC to respond, but > I do appreciate the way you have been following our requested process on > the security page which I helped revise. Once I saw your second mail, I > initiated a small private list discussion to try to ensure a coherent > response since it didn't seem to have been addressed previously. It doesn't > look like there is much risk from this one since it's at most a DOS and > would only be encountered by users that are using text tagging > functionality since that is the only place we use this library directly. I > also see it as a transitive dependency in some of the s3 related code, but > is not directly used by us in that module. While there is processing of > external data in this path, this would generally be indexing related, which > makes a DOS a bit difficult to achieve. This is based on initial quick > look/discussion, but there has been no serious attempt to > find/verify/exclude an exploit since it's getting fixed soon as part of > other work, so YMMV. > > -Gus > > On Tue, Nov 29, 2022 at 8:30 AM Billy Kidwell > <bkidw...@opentext.com.invalid> > wrote: > > > https://nvd.nist.gov/vuln/detail/CVE-2022-40153 > > > > Our container scan found a potential security vulnerability in Solr 9.0.0 > > and 9.1.0 for woodstox-core. > > > > I checked the security page, the official list of non-exploitable > > vulnerabilities and the user mailing list. I also checked jira. There > are > > a number of tickets concerning woodstox, but they seem to be prior > issues. > > > > For 9.1.0, the package version seems to be 6.2.8 > > > > /solr/server/solr-webapp/webapp/WEB-INF/lib/woodstox-core-6.2.8.jar > > > > This vulnerability is addressed in 6.4.0. > > > > Does anyone know if this vulnerability is exploitable in Solr? > > If so, under what circumstances? > > > > Thanks, > > > > Bill > > > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) >
