Cybersecurity Incident Report

2020-07-21 Thread Man with No Name
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


Re: Cybersecurity Incident Report

2020-07-22 Thread Man with No Name
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

2020-07-23 Thread Man with No Name
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-20

Re: Cybersecurity Incident Report

2020-08-06 Thread 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