Re: Cybersecurity Incident Report
If you suspect a new vulnerability in the product, please report as detailed on our security page: https://lucene.apache.org/solr/security.html For these existing ones, you may first check whether upgrades are already done in 8.5 or 8.6, and if not, check if there is an open JIRA issue about upgrading these dependencies, and if not kindly open a new JIRA issue about such upgrades. And if you are willing to contribute, a patch or PR is highly welcome too :) Jan > 7. aug. 2020 kl. 05:03 skrev Man with No Name : > > You’re absolutely right. Some of these are shadow jars and sone directly > used. Like netty, we're securing the communication using tls and the netty > cve applies. > > So going back to the initial question, what would be the best way to > report this, so that it can be looked at? > > On Fri, Jul 24, 2020 at 7:35 PM Shawn Heisey wrote: > >> On 7/24/2020 2:35 PM, Man with No Name wrote: >>> This version of jackson is pulled in as a shadow jar. Also solr is using >>> io.netty version 4.1.29.Final which has critical vulnerabilities which >>> are fixed in 4.1.44. >> >> It looks like that shaded jackson library is included in the jar for >> htrace. I looked through the commit history and learned that htrace is >> included for the HDFS support in Solr. Which means that if you are not >> using the HDFS capability, then htrace will not be used, so the older >> jackson library will not be used either. >> >> If you are not using TLS connections from SolrCloud to ZooKeeper, then >> your install of Solr will not be using the netty library, and >> vulnerabilities in netty will not apply. >> >> The older version of Guava is pulled in with a jar from carrot2. If >> your Solr install does not use carrot2 clustering, then that version of >> Guava will never be called. >> >> The commons-compress and tika libraries are only used if you have >> configured the extraction contrib, also known as SolrCell. This contrib >> module is used to index rich-text documents, such as PDF and Word. >> Because it makes Solr unstable, we strongly recommend that nobody should >> use SolrCell in production. When rich-text documents need to be >> indexed, it should be accomplished by using Tika outside of Solr... and >> if that recommendation is followed, you can control the version used so >> that the well-known vulnerabilities will not be present. >> >> We have always recommended that Solr should be located in a network >> place that can only be reached by systems and people who are authorized. >> If that is done, then nobody will be able to exploit any >> vulnerabilities that might exist in Solr unless they first successfully >> break into an authorized system. >> >> We do take these reports of vulnerabilities seriously and close them as >> quickly as we can. >> >> Thanks, >> Shawn >> > -- > Sent from Gmail for IPhone
Re: Cybersecurity Incident Report
You’re absolutely right. Some of these are shadow jars and sone directly used. Like netty, we're securing the communication using tls and the netty cve applies. So going back to the initial question, what would be the best way to report this, so that it can be looked at? On Fri, Jul 24, 2020 at 7:35 PM Shawn Heisey wrote: > On 7/24/2020 2:35 PM, Man with No Name wrote: > > This version of jackson is pulled in as a shadow jar. Also solr is using > > io.netty version 4.1.29.Final which has critical vulnerabilities which > > are fixed in 4.1.44. > > It looks like that shaded jackson library is included in the jar for > htrace. I looked through the commit history and learned that htrace is > included for the HDFS support in Solr. Which means that if you are not > using the HDFS capability, then htrace will not be used, so the older > jackson library will not be used either. > > If you are not using TLS connections from SolrCloud to ZooKeeper, then > your install of Solr will not be using the netty library, and > vulnerabilities in netty will not apply. > > The older version of Guava is pulled in with a jar from carrot2. If > your Solr install does not use carrot2 clustering, then that version of > Guava will never be called. > > The commons-compress and tika libraries are only used if you have > configured the extraction contrib, also known as SolrCell. This contrib > module is used to index rich-text documents, such as PDF and Word. > Because it makes Solr unstable, we strongly recommend that nobody should > use SolrCell in production. When rich-text documents need to be > indexed, it should be accomplished by using Tika outside of Solr... and > if that recommendation is followed, you can control the version used so > that the well-known vulnerabilities will not be present. > > We have always recommended that Solr should be located in a network > place that can only be reached by systems and people who are authorized. > If that is done, then nobody will be able to exploit any > vulnerabilities that might exist in Solr unless they first successfully > break into an authorized system. > > We do take these reports of vulnerabilities seriously and close them as > quickly as we can. > > Thanks, > Shawn > -- Sent from Gmail for IPhone
Re: Cybersecurity Incident Report
On 7/24/2020 2:35 PM, Man with No Name wrote: This version of jackson is pulled in as a shadow jar. Also solr is using io.netty version 4.1.29.Final which has critical vulnerabilities which are fixed in 4.1.44. It looks like that shaded jackson library is included in the jar for htrace. I looked through the commit history and learned that htrace is included for the HDFS support in Solr. Which means that if you are not using the HDFS capability, then htrace will not be used, so the older jackson library will not be used either. If you are not using TLS connections from SolrCloud to ZooKeeper, then your install of Solr will not be using the netty library, and vulnerabilities in netty will not apply. The older version of Guava is pulled in with a jar from carrot2. If your Solr install does not use carrot2 clustering, then that version of Guava will never be called. The commons-compress and tika libraries are only used if you have configured the extraction contrib, also known as SolrCell. This contrib module is used to index rich-text documents, such as PDF and Word. Because it makes Solr unstable, we strongly recommend that nobody should use SolrCell in production. When rich-text documents need to be indexed, it should be accomplished by using Tika outside of Solr... and if that recommendation is followed, you can control the version used so that the well-known vulnerabilities will not be present. We have always recommended that Solr should be located in a network place that can only be reached by systems and people who are authorized. If that is done, then nobody will be able to exploit any vulnerabilities that might exist in Solr unless they first successfully break into an authorized system. We do take these reports of vulnerabilities seriously and close them as quickly as we can. Thanks, Shawn
Re: Cybersecurity Incident Report
docker pull solr:8.4.1-slim docker run -it --rm solr:8.4.1-slim /bin/bash solr@223042112be5:/opt/solr-8.4.1$ find ./ -name "*jackson*" ./server/solr-webapp/webapp/WEB-INF/lib/jackson-core-2.10.0.jar ./server/solr-webapp/webapp/WEB-INF/lib/jackson-annotations-2.10.0.jar ./server/solr-webapp/webapp/WEB-INF/lib/jackson-dataformat-smile-2.10.0.jar ./server/solr-webapp/webapp/WEB-INF/lib/jackson-databind-2.10.0.jar ./contrib/prometheus-exporter/lib/jackson-jq-0.0.8.jar ./contrib/prometheus-exporter/lib/jackson-core-2.10.0.jar ./contrib/prometheus-exporter/lib/jackson-annotations-2.10.0.jar ./contrib/prometheus-exporter/lib/jackson-databind-2.10.0.jar ./contrib/clustering/lib/jackson-annotations-2.10.0.jar ./contrib/clustering/lib/jackson-databind-2.10.0.jar How does the scanner work? On Thu, Jul 23, 2020 at 11:23 PM Man with No Name wrote: > > Any help on this.? > > On Wed, Jul 22, 2020 at 4:25 PM Man with No Name > wrote: > > > The image is pulled from docker hub. After scanning the image from docker > > hub, without any modification, this is the list of CVE we're getting. > > > > > > Image ID CVE Package > > Version SeverityStatus > >CVSS > > - -- --- --- > > --- -- > > > > solr:8.4.1-slim57561b4889690532CVE-2019-16335 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2020-8840 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > > 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2020-11620 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10.49.8 > > solr:8.4.1-slim57561b4889690532CVE-2020-9546 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10.49.8 > > solr:8.4.1-slim57561b4889690532CVE-2020-9547 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10.49.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-20445 > > io.netty_netty-codec 4.1.29.Finalcritical > >fixed in 4.1.44 9.1 > > solr:8.4.1-slim57561b4889690532CVE-2020-9548 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10.49.8 > > solr:8.4.1-slim57561b4889690532CVE-2017-15095 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.1, 2.8.10 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2018-14718 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.7 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-16942 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > > 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-14893 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.10.0, 2.9.10 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2018-7489 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.5, 2.8.11.1, 2.7.9.39.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-20444 > > io.netty_netty-codec 4.1.29.Finalcritical > >fixed in 4.1.44 9.1 > > solr:8.4.1-slim57561b4889690532CVE-2019-14540 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-16943 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > > 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2020-11612 > > io.netty_netty-codec 4.1.29.Finalcritical > >fixed in 4.1.46 9.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-20330 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10.29.8 > > solr:8.4.1-slim57561b4889690532CVE-2019-17267 > > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > >fixed in 2.9.10 9.8 > > > > > > On Tue, Jul 21, 2020 at
Re: Cybersecurity Incident Report
Any help on this.? On Wed, Jul 22, 2020 at 4:25 PM Man with No Name wrote: > The image is pulled from docker hub. After scanning the image from docker > hub, without any modification, this is the list of CVE we're getting. > > > Image ID CVE Package > Version SeverityStatus >CVSS > - -- --- --- > --- -- > > solr:8.4.1-slim57561b4889690532CVE-2019-16335 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10 9.8 > solr:8.4.1-slim57561b4889690532CVE-2020-8840 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > 9.8 > solr:8.4.1-slim57561b4889690532CVE-2020-11620 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10.49.8 > solr:8.4.1-slim57561b4889690532CVE-2020-9546 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10.49.8 > solr:8.4.1-slim57561b4889690532CVE-2020-9547 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10.49.8 > solr:8.4.1-slim57561b4889690532CVE-2019-20445 > io.netty_netty-codec 4.1.29.Finalcritical > fixed in 4.1.44 9.1 > solr:8.4.1-slim57561b4889690532CVE-2020-9548 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10.49.8 > solr:8.4.1-slim57561b4889690532CVE-2017-15095 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.1, 2.8.10 9.8 > solr:8.4.1-slim57561b4889690532CVE-2018-14718 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.7 9.8 > solr:8.4.1-slim57561b4889690532CVE-2019-16942 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > 9.8 > solr:8.4.1-slim57561b4889690532CVE-2019-14893 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.10.0, 2.9.10 9.8 > solr:8.4.1-slim57561b4889690532CVE-2018-7489 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.5, 2.8.11.1, 2.7.9.39.8 > solr:8.4.1-slim57561b4889690532CVE-2019-20444 > io.netty_netty-codec 4.1.29.Finalcritical > fixed in 4.1.44 9.1 > solr:8.4.1-slim57561b4889690532CVE-2019-14540 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10 9.8 > solr:8.4.1-slim57561b4889690532CVE-2019-16943 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > 9.8 > solr:8.4.1-slim57561b4889690532CVE-2020-11612 > io.netty_netty-codec 4.1.29.Finalcritical > fixed in 4.1.46 9.8 > solr:8.4.1-slim57561b4889690532CVE-2019-20330 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10.29.8 > solr:8.4.1-slim57561b4889690532CVE-2019-17267 > com.fasterxml.jackson.core_jackson-databind2.4.0 critical > fixed in 2.9.10 9.8 > > > On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson > wrote: > >> Not sure where the Docker image came from, but according to: >> https://issues.apache.org/jira/browse/SOLR-13818 >> >> Jackson was upgraded to 2.10.0 in Solr 8.4. >> >> > On Jul 21, 2020, at 2:59 PM, Man with No Name < >> pinkeshsharm...@gmail.com> wrote: >> > >> > Hey Guys, >> > Our team is using Solr 8.4.1 in a kubernetes cluster using the public >> image >> > from docker hub. The containers before getting deployed to the cluster >> > get whitescanned and it lists all the CVEs in the container. This is >> list >> > of CVE we have for Solr >> > >> > CVE-2020-11619, CVE-2020-11620, CVE-2020-8840, CVE-2019-10088, >> > CVE-2020-10968, CVE-2020-10969, CVE-2020-1, CVE-2020-2, >> > CVE-2020-3, CVE-2020-14060, CVE-2020-14061, CVE-2020-14062, >> > CVE-2020-14195, CVE-2019-10094, CVE-2019-12402 >> > >> > Most of the CVEs are because of the old version of Jackson-databind, >> and it >> > has been fixed in the 2.9.10.4 version. So what would
Re: Cybersecurity Incident Report
The image is pulled from docker hub. After scanning the image from docker hub, without any modification, this is the list of CVE we're getting. Image ID CVE Package Version Severity Status CVSS - -- --- --- --- -- solr:8.4.1-slim57561b4889690532CVE-2019-16335 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10 9.8 solr:8.4.1-slim57561b4889690532CVE-2020-8840 com.fasterxml.jackson.core_jackson-databind2.4.0 critical 9.8 solr:8.4.1-slim57561b4889690532CVE-2020-11620 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10.49.8 solr:8.4.1-slim57561b4889690532CVE-2020-9546 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10.49.8 solr:8.4.1-slim57561b4889690532CVE-2020-9547 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10.49.8 solr:8.4.1-slim57561b4889690532CVE-2019-20445 io.netty_netty-codec 4.1.29.Final criticalfixed in 4.1.44 9.1 solr:8.4.1-slim57561b4889690532CVE-2020-9548 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10.49.8 solr:8.4.1-slim57561b4889690532CVE-2017-15095 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.1, 2.8.10 9.8 solr:8.4.1-slim57561b4889690532CVE-2018-14718 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.7 9.8 solr:8.4.1-slim57561b4889690532CVE-2019-16942 com.fasterxml.jackson.core_jackson-databind2.4.0 critical 9.8 solr:8.4.1-slim57561b4889690532CVE-2019-14893 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.10.0, 2.9.10 9.8 solr:8.4.1-slim57561b4889690532CVE-2018-7489 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.5, 2.8.11.1, 2.7.9.39.8 solr:8.4.1-slim57561b4889690532CVE-2019-20444 io.netty_netty-codec 4.1.29.Final criticalfixed in 4.1.44 9.1 solr:8.4.1-slim57561b4889690532CVE-2019-14540 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10 9.8 solr:8.4.1-slim57561b4889690532CVE-2019-16943 com.fasterxml.jackson.core_jackson-databind2.4.0 critical 9.8 solr:8.4.1-slim57561b4889690532CVE-2020-11612 io.netty_netty-codec 4.1.29.Final criticalfixed in 4.1.46 9.8 solr:8.4.1-slim57561b4889690532CVE-2019-20330 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10.29.8 solr:8.4.1-slim57561b4889690532CVE-2019-17267 com.fasterxml.jackson.core_jackson-databind2.4.0 criticalfixed in 2.9.10 9.8 On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson wrote: > Not sure where the Docker image came from, but according to: > https://issues.apache.org/jira/browse/SOLR-13818 > > Jackson was upgraded to 2.10.0 in Solr 8.4. > > > On Jul 21, 2020, at 2:59 PM, Man with No Name > wrote: > > > > Hey Guys, > > Our team is using Solr 8.4.1 in a kubernetes cluster using the public > image > > from docker hub. The containers before getting deployed to the cluster > > get whitescanned and it lists all the CVEs in the container. This is list > > of CVE we have for Solr > > > > CVE-2020-11619, CVE-2020-11620, CVE-2020-8840, CVE-2019-10088, > > CVE-2020-10968, CVE-2020-10969, CVE-2020-1, CVE-2020-2, > > CVE-2020-3, CVE-2020-14060, CVE-2020-14061, CVE-2020-14062, > > CVE-2020-14195, CVE-2019-10094, CVE-2019-12402 > > > > Most of the CVEs are because of the old version of Jackson-databind, and > it > > has been fixed in the 2.9.10.4 version. So what would be the best way to > > report this and to get it fixed? > > > > > > CVE is a list of entries — each containing an identification number, a > > description, and at least one public reference — for publicly known > > cybersecurity vulnerabilities. > > > > -- > > Regards: > > Pinkesh Sharma > > -- Regards: Pinkesh Sharma
Re: Cybersecurity Incident Report
Not sure where the Docker image came from, but according to: https://issues.apache.org/jira/browse/SOLR-13818 Jackson was upgraded to 2.10.0 in Solr 8.4. > On Jul 21, 2020, at 2:59 PM, Man with No Name > wrote: > > Hey Guys, > Our team is using Solr 8.4.1 in a kubernetes cluster using the public image > from docker hub. The containers before getting deployed to the cluster > get whitescanned and it lists all the CVEs in the container. This is list > of CVE we have for Solr > > CVE-2020-11619, CVE-2020-11620, CVE-2020-8840, CVE-2019-10088, > CVE-2020-10968, CVE-2020-10969, CVE-2020-1, CVE-2020-2, > CVE-2020-3, CVE-2020-14060, CVE-2020-14061, CVE-2020-14062, > CVE-2020-14195, CVE-2019-10094, CVE-2019-12402 > > Most of the CVEs are because of the old version of Jackson-databind, and it > has been fixed in the 2.9.10.4 version. So what would be the best way to > report this and to get it fixed? > > > CVE is a list of entries — each containing an identification number, a > description, and at least one public reference — for publicly known > cybersecurity vulnerabilities. > > -- > Regards: > Pinkesh Sharma
Cybersecurity Incident Report
Hey Guys, Our team is using Solr 8.4.1 in a kubernetes cluster using the public image from docker hub. The containers before getting deployed to the cluster get whitescanned and it lists all the CVEs in the container. This is list of CVE we have for Solr CVE-2020-11619, CVE-2020-11620, CVE-2020-8840, CVE-2019-10088, CVE-2020-10968, CVE-2020-10969, CVE-2020-1, CVE-2020-2, CVE-2020-3, CVE-2020-14060, CVE-2020-14061, CVE-2020-14062, CVE-2020-14195, CVE-2019-10094, CVE-2019-12402 Most of the CVEs are because of the old version of Jackson-databind, and it has been fixed in the 2.9.10.4 version. So what would be the best way to report this and to get it fixed? CVE is a list of entries — each containing an identification number, a description, and at least one public reference — for publicly known cybersecurity vulnerabilities. -- Regards: Pinkesh Sharma
