You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Man with No Name <pi...@gmail.com> on 2020/07/21 18:59:52 UTC
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-11111, CVE-2020-11112,
CVE-2020-11113, 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
Re: Cybersecurity Incident Report
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <pi...@gmail.com>:
>
> 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 <ap...@elyograg.org> 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
Posted by Man with No Name <pi...@gmail.com>.
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 <ap...@elyograg.org> 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
Posted by Shawn Heisey <ap...@elyograg.org>.
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
Posted by Man with No Name <pi...@gmail.com>.
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.
I'm attaching the list of CVE for solr base image with complete scan
details, including how the library was introduced in the image.
On Fri, Jul 24, 2020 at 8:59 AM matthew sporleder <ms...@gmail.com>
wrote:
> 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
> <pi...@gmail.com> wrote:
> >
> > Any help on this.?
> >
> > On Wed, Jul 22, 2020 at 4:25 PM Man with No Name <
> pinkeshsharma89@gmail.com>
> > 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 Severity Status
> CVSS
> > > ----- -- --- -------
> ------- -------- ------
> ----
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-16335
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-8840
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-11620
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10.4 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-9546
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10.4 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-9547
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10.4 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-20445
> io.netty_netty-codec 4.1.29.Final
> critical fixed in 4.1.44 9.1
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-9548
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10.4 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2017-15095
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.1, 2.8.10 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2018-14718
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.7 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-16942
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-14893
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.10.0, 2.9.10 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2018-7489
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.5, 2.8.11.1, 2.7.9.3 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-20444
> io.netty_netty-codec 4.1.29.Final
> critical fixed in 4.1.44 9.1
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-14540
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-16943
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2020-11612
> io.netty_netty-codec 4.1.29.Final
> critical fixed in 4.1.46 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-20330
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10.2 9.8
> > > solr:8.4.1-slim 57561b4889690532 CVE-2019-17267
> com.fasterxml.jackson.core_jackson-databind 2.4.0
> critical fixed in 2.9.10 9.8
> > >
> > >
> > > On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson <
> erickerickson@gmail.com>
> > > 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 <
> > >> pinkeshsharma89@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-11111, CVE-2020-11112,
> > >> > CVE-2020-11113, 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
> > >
> > --
> > Sent from Gmail for IPhone
>
--
Regards:
Pinkesh Sharma
Re: Cybersecurity Incident Report
Posted by matthew sporleder <ms...@gmail.com>.
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
<pi...@gmail.com> wrote:
>
> Any help on this.?
>
> On Wed, Jul 22, 2020 at 4:25 PM Man with No Name <pi...@gmail.com>
> 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 Severity Status CVSS
> > ----- -- --- ------- ------- -------- ------ ----
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-16335 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-8840 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-11620 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-9546 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-9547 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-20445 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.44 9.1
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-9548 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2017-15095 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.1, 2.8.10 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2018-14718 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.7 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-16942 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-14893 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.10.0, 2.9.10 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2018-7489 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.5, 2.8.11.1, 2.7.9.3 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-20444 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.44 9.1
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-14540 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-16943 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2020-11612 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.46 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-20330 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.2 9.8
> > solr:8.4.1-slim 57561b4889690532 CVE-2019-17267 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
> >
> >
> > On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson <er...@gmail.com>
> > 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 <
> >> pinkeshsharma89@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-11111, CVE-2020-11112,
> >> > CVE-2020-11113, 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
> >
> --
> Sent from Gmail for IPhone
Re: Cybersecurity Incident Report
Posted by Man with No Name <pi...@gmail.com>.
Any help on this.?
On Wed, Jul 22, 2020 at 4:25 PM Man with No Name <pi...@gmail.com>
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 Severity Status CVSS
> ----- -- --- ------- ------- -------- ------ ----
> solr:8.4.1-slim 57561b4889690532 CVE-2019-16335 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2020-8840 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2020-11620 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2020-9546 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2020-9547 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-20445 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.44 9.1
> solr:8.4.1-slim 57561b4889690532 CVE-2020-9548 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.4 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2017-15095 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.1, 2.8.10 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2018-14718 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.7 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-16942 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-14893 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.10.0, 2.9.10 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2018-7489 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.5, 2.8.11.1, 2.7.9.3 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-20444 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.44 9.1
> solr:8.4.1-slim 57561b4889690532 CVE-2019-14540 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-16943 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2020-11612 io.netty_netty-codec 4.1.29.Final critical fixed in 4.1.46 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-20330 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10.2 9.8
> solr:8.4.1-slim 57561b4889690532 CVE-2019-17267 com.fasterxml.jackson.core_jackson-databind 2.4.0 critical fixed in 2.9.10 9.8
>
>
> On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson <er...@gmail.com>
> 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 <
>> pinkeshsharma89@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-11111, CVE-2020-11112,
>> > CVE-2020-11113, 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
>
--
Sent from Gmail for IPhone
Re: Cybersecurity Incident Report
Posted by Man with No Name <pi...@gmail.com>.
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-slim 57561b4889690532 CVE-2019-16335
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2020-8840
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2020-11620
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10.4 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2020-9546
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10.4 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2020-9547
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10.4 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-20445
io.netty_netty-codec 4.1.29.Final
critical fixed in 4.1.44 9.1
solr:8.4.1-slim 57561b4889690532 CVE-2020-9548
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10.4 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2017-15095
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.1, 2.8.10 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2018-14718
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.7 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-16942
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-14893
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.10.0, 2.9.10 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2018-7489
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.5, 2.8.11.1, 2.7.9.3 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-20444
io.netty_netty-codec 4.1.29.Final
critical fixed in 4.1.44 9.1
solr:8.4.1-slim 57561b4889690532 CVE-2019-14540
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-16943
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2020-11612
io.netty_netty-codec 4.1.29.Final
critical fixed in 4.1.46 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-20330
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10.2 9.8
solr:8.4.1-slim 57561b4889690532 CVE-2019-17267
com.fasterxml.jackson.core_jackson-databind 2.4.0
critical fixed in 2.9.10 9.8
On Tue, Jul 21, 2020 at 5:06 PM Erick Erickson <er...@gmail.com>
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 <pi...@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-11111, CVE-2020-11112,
> > CVE-2020-11113, 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
Posted by Erick Erickson <er...@gmail.com>.
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 <pi...@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-11111, CVE-2020-11112,
> CVE-2020-11113, 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