Re: SOLR v7 Security Issues Caused Denial of Use - Sonatype Application Composition Report
Hi Shawn, Thanks for the great answers. Thanks also to Jörn Franke and Gus Heck for responses. The images were sent for convenience of the issues listed below them. We are working to get infosec approval. It would be helpful to put the security links prominently on the solr splash and download pages. I also found these links to be useful: This is the Solr Security Wiki page with a list of CVE’s which Sonatype reports. https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools Apache <https://www.cvedetails.com/vendor/45/Apache.html> » Solr <https://www.cvedetails.com/product/18263/Apache-Solr.html?vendor_id=45> : Security Vulnerabilities https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-18263/Apache-Solr.html -- Forwarded message - From: Shawn Heisey Date: Fri, Jan 4, 2019 at 1:49 PM Subject: Re: SOLR v7 Security Issues Caused Denial of Use - Sonatype Application Composition Report To: On 1/3/2019 11:15 AM, Bob Hathaway wrote: > We want to use SOLR v7 but Sonatype scans past v6.5 show dozens of > critical and severe security issues and dozens of licensing issues. None of the images that you attached to your message are visible to us. Attachments are regularly stripped by Apache mailing lists and cannot be relied on. Some of the security issues you've mentioned could be problems. But if you follow recommendations and make sure that Solr is not directly accessible to unauthorized parties, it will not be possible for those parties to exploit security issues without first finding and exploiting a vulnerability on an authorized system. Vulnerabilities in SolrJ, if any exist, are slightly different, but unless unauthorized parties have the ability to *directly* send input to SolrJ code without intermediate code sanitizing the input, they will not be able to exploit those vulnerabilities. JSON support in SolrJ is provided by noggit, not jackson, and JSON/XML are not used by recent versions of SolrJ unless they are very specifically requested by the programmer. Are there any vulnerabilities you've found that affect SolrJ itself, separately from the rest of Solr? As we become aware of issues with either project code or third-party software, we get them fixed. Sometimes it is not completely straightforward to upgrade to newer versions of third-party software, but staying current is a priority. Licensing issues are of major concern to the entire Apache Foundation. As a project, we are unaware of any licensing problems at this time. All of the third-party software that is included with Solr should be available under a license that is compatible with the Apache license. I didn't examine the list you sent super closely, but what I did look at didn't look like a problem. https://www.apache.org/legal/resolved.html#category-b The mere presence of GPL in the available licenses for third party software is not an indication of a problem. If that were the ONLY license available, then it would be a problem. Thanks, Shawn
Re: SOLR v7 Security Issues Caused Denial of Use - Sonatype Application Composition Report
The most important feature of any software running today is that it can be run at all. Security vulnerabilities can preclude software from running in enterprise environments. Today software must be free of critical and severe security vulnerabilities or they can't be run at all from Information Security policies. Enterprises today run security scan software to check for security and licensing vulnerabilities because today most organizations are using open source software where this has become most relevant. Forrester has a good summary on the need for software composition analysis tools which virtually all enterprises run today befor allowing software to run in production environments: https://www.blackducksoftware.com/sites/default/files/images/Downloads/Reports/USA/ForresterWave-Rpt.pdf Solr version 6.5 passes security scans showing no critical security issues. Solr version 7 fails security scans with over a dozen critical and severe security vulnerabilities for Solr version from 7.1. Then we ran scans against the latest Solr version 7.6 which failed as well. Most of the issues are due to using old libraries including the JSON Jackson framework, Dom 4j and Xerces and should be easy to bring up to date. Only the latest version of SimpleXML has severe security vulnerabilities. Derby leads the most severe security violations at Level 9.1 by using an out of date version. What good is software or any features if enterprises can't run them? Today software cybersecurity is a top priority and risk for enterprises. Solr version 6.5 is very old exposing the zookeeper backend from the SolrJ client which is a differentiating capability. Is security and remediation a priority for SolrJ? I believe this should be a top feature to allow SolrJ to continue providing search features to enterprises and a security roadmap and plan to keep Solr secure and usable by continually adapting and improving in the ever changing security landscape and ecosystem. The Darby vulnerability issue CVE-2015-1832 was a passing medium Level 6.2 issue in CVSS 2.0 last year but is the most critical issue with Solr 7.6 at Level 9.1 in this year's CVSS 3.0. These changes need to be tracked and updates and fixes incorporated into new Solr versions. https://nvd.nist.gov/vuln/detail/CVE-2015-1832 On Thu, Jan 3, 2019 at 12:19 PM Bob Hathaway wrote: > Critical and Severe security vulnerabilities against Solr v7.1. Many of > these appear to be from old open source framework versions. > > *9* CVE-2017-7525 com.fasterxml.jackson.core : jackson-databind : 2.5.4 > Open > >CVE-2016-131 commons-fileupload : commons-fileupload : 1.3.2 Open > >CVE-2015-1832 org.apache.derby : derby : 10.9.1.0 Open > >CVE-2017-7525 org.codehaus.jackson : jackson-mapper-asl : 1.9.13 Open > >CVE-2017-7657 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open > >CVE-2017-7658 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open > >CVE-2017-1000190 org.simpleframework : simple-xml : 2.7.1 Open > > *7* sonatype-2016-0397 com.fasterxml.jackson.core : jackson-core : 2.5.4 > Open > >sonatype-2017-0355 com.fasterxml.jackson.core : jackson-core : 2.5.4 > Open > >CVE-2014-0114 commons-beanutils : commons-beanutils : 1.8.3 Open > >CVE-2018-1000632 dom4j : dom4j : 1.6.1 Open > >CVE-2018-8009 org.apache.hadoop : hadoop-common : 2.7.4 Open > >CVE-2017-12626 org.apache.poi : poi : 3.17-beta1 Open > >CVE-2017-12626 org.apache.poi : poi-scratchpad : 3.17-beta1 Open > >CVE-2018-1308 org.apache.solr : solr-dataimporthandler : 7.1.0 Open > >CVE-2016-4434 org.apache.tika : tika-core : 1.16 Open > >CVE-2018-11761 org.apache.tika : tika-core : 1.16 Open > >CVE-2016-1000338 org.bouncycastle : bcprov-jdk15 : 1.45 Open > >CVE-2016-1000343 org.bouncycastle : bcprov-jdk15 : 1.45 Open > >CVE-2018-1000180 org.bouncycastle : bcprov-jdk15 : 1.45 Open > >CVE-2017-7656 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open > >CVE-2012-0881 xerces : xercesImpl : 2.9.1 Open > >CVE-2013-4002 xerces : xercesImpl : 2.9.1 Open > > On Thu, Jan 3, 2019 at 12:15 PM Bob Hathaway wrote: > >> We want to use SOLR v7 but Sonatype scans past v6.5 show dozens of >> critical and severe security issues and dozens of licensing issues. The >> critical security violations using Sonatype are inline and are indexed with >> codes from the National Vulnerability Database, >> >> Are there recommended steps for running Solr 7 in secure enterprises >> specifically infosec remediation over Sonatype Application Composition >> Reports? >> >> Are there plans to make Solr more secure in v7 or v8? >> >> I'm new to the Solr User forum and suggests are welcome. >> >> >> Son
Re: SOLR v7 Security Issues Caused Denial of Use - Sonatype Application Composition Report
Critical and Severe security vulnerabilities against Solr v7.1. Many of these appear to be from old open source framework versions. *9* CVE-2017-7525 com.fasterxml.jackson.core : jackson-databind : 2.5.4 Open CVE-2016-131 commons-fileupload : commons-fileupload : 1.3.2 Open CVE-2015-1832 org.apache.derby : derby : 10.9.1.0 Open CVE-2017-7525 org.codehaus.jackson : jackson-mapper-asl : 1.9.13 Open CVE-2017-7657 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open CVE-2017-7658 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open CVE-2017-1000190 org.simpleframework : simple-xml : 2.7.1 Open *7* sonatype-2016-0397 com.fasterxml.jackson.core : jackson-core : 2.5.4 Open sonatype-2017-0355 com.fasterxml.jackson.core : jackson-core : 2.5.4 Open CVE-2014-0114 commons-beanutils : commons-beanutils : 1.8.3 Open CVE-2018-1000632 dom4j : dom4j : 1.6.1 Open CVE-2018-8009 org.apache.hadoop : hadoop-common : 2.7.4 Open CVE-2017-12626 org.apache.poi : poi : 3.17-beta1 Open CVE-2017-12626 org.apache.poi : poi-scratchpad : 3.17-beta1 Open CVE-2018-1308 org.apache.solr : solr-dataimporthandler : 7.1.0 Open CVE-2016-4434 org.apache.tika : tika-core : 1.16 Open CVE-2018-11761 org.apache.tika : tika-core : 1.16 Open CVE-2016-1000338 org.bouncycastle : bcprov-jdk15 : 1.45 Open CVE-2016-1000343 org.bouncycastle : bcprov-jdk15 : 1.45 Open CVE-2018-1000180 org.bouncycastle : bcprov-jdk15 : 1.45 Open CVE-2017-7656 org.eclipse.jetty : jetty-http : 9.3.20.v20170531 Open CVE-2012-0881 xerces : xercesImpl : 2.9.1 Open CVE-2013-4002 xerces : xercesImpl : 2.9.1 Open On Thu, Jan 3, 2019 at 12:15 PM Bob Hathaway wrote: > We want to use SOLR v7 but Sonatype scans past v6.5 show dozens of > critical and severe security issues and dozens of licensing issues. The > critical security violations using Sonatype are inline and are indexed with > codes from the National Vulnerability Database, > > Are there recommended steps for running Solr 7 in secure enterprises > specifically infosec remediation over Sonatype Application Composition > Reports? > > Are there plans to make Solr more secure in v7 or v8? > > I'm new to the Solr User forum and suggests are welcome. > > > Sonatype Application Composition Reports > Of Solr - 7.6.0, Build Scanned On Thu Jan 03 2019 at 14:49:49 > Using Scanner 1.56.0-01 > > [image: image.png] > > [image: image.png] > > [image: image.png] > > Security Issues > Threat Level Problem Code Component Status > 9 CVE-2015-1832 org.apache.derby : derby : 10.9.1.0 Open > CVE-2017-7525 org.codehaus.jackson : jackson-mapper-asl : 1.9.13 Open > CVE-2017-1000 > 190 > org.simpleframework : simple-xml : 2.7.1 Open > 8 CVE-2018-1471 > 8 > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > CVE-2018-1471 > 9 > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > sonatype-2017- > 0312 > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > 7 CVE-2018-1472 > 0 > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > CVE-2018-1472 > 1 > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > CVE-2018-1000 > 632 > dom4j : dom4j : 1.6.1 Open > CVE-2018-8009 org.apache.hadoop : hadoop-common : 2.7.4 Open > CVE-2012-0881 xerces : xercesImpl : 2.9.1 Open > CVE-2013-4002 xerces : xercesImpl : 2.9.1 Open > > > License Analysis > License Threat Component Status > MPL-1.1, GPL-2.0+ or > LGPL-2.1+ or MPL-1.1 > com.googlecode.juniversalchardet : juniversalchardet : 1.0.3 Open > Apache-2.0, AFL-2.1 or > GPL-2.0+ > org.ccil.cowan.tagsoup : tagsoup : 1.2.1 Open > Not Declared, Not > Supported > d3 2.9.6 Open > BSD-3-Clause, Adobe com.adobe.xmp : xmpcore : 5.1.3 Open > Apache-2.0, No Source > License > com.cybozu.labs : langdetect : 1.1-20120112 Open > Apache-2.0, No Source > License > com.fasterxml.jackson.core : jackson-annotations : 2.9.6 Open > Apache-2.0, No Source > License > com.fasterxml.jackson.core : jackson-core : 2.9.6 Open > Apache-2.0, No Source > License > com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open > Apache-2.0, No Source > License > com.fasterxml.jackson.dataformat : jackson-dataformat-smile : 2.9.6 Open > Apache-2.0, EPL-1.0, MIT com.googlecode.mp4parser : isoparser : 1.1.22 Open > Not Provided, No Source > License > com.ibm.icu : icu4j : 62.1 Open > Apache-2.0, LGPL-3.0+ com.pff : java-libpst : 0.8.1 Open > Apache-2.0, No Source > License > com.rometools : rome-utils : 1.5.1 Open > CDDL-1.1 or GPL-2.0- > CPE > com.sun.mail : gimap : 1.5.1 Open > CDDL-1.1 or GPL-2.0- > CPE > com.sun.mail : javax.mail : 1.5.1 Open > Not Declared, > Apache-1.1, Sun-IP > dom4j : dom4j : 1.6.1 Open > MIT,
SOLR v7 Security Issues Caused Denial of Use - Sonatype Application Composition Report
We want to use SOLR v7 but Sonatype scans past v6.5 show dozens of critical and severe security issues and dozens of licensing issues. The critical security violations using Sonatype are inline and are indexed with codes from the National Vulnerability Database, Are there recommended steps for running Solr 7 in secure enterprises specifically infosec remediation over Sonatype Application Composition Reports? Are there plans to make Solr more secure in v7 or v8? I'm new to the Solr User forum and suggests are welcome. Sonatype Application Composition Reports Of Solr - 7.6.0, Build Scanned On Thu Jan 03 2019 at 14:49:49 Using Scanner 1.56.0-01 [image: image.png] [image: image.png] [image: image.png] Security Issues Threat Level Problem Code Component Status 9 CVE-2015-1832 org.apache.derby : derby : 10.9.1.0 Open CVE-2017-7525 org.codehaus.jackson : jackson-mapper-asl : 1.9.13 Open CVE-2017-1000 190 org.simpleframework : simple-xml : 2.7.1 Open 8 CVE-2018-1471 8 com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open CVE-2018-1471 9 com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open sonatype-2017- 0312 com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open 7 CVE-2018-1472 0 com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open CVE-2018-1472 1 com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open CVE-2018-1000 632 dom4j : dom4j : 1.6.1 Open CVE-2018-8009 org.apache.hadoop : hadoop-common : 2.7.4 Open CVE-2012-0881 xerces : xercesImpl : 2.9.1 Open CVE-2013-4002 xerces : xercesImpl : 2.9.1 Open License Analysis License Threat Component Status MPL-1.1, GPL-2.0+ or LGPL-2.1+ or MPL-1.1 com.googlecode.juniversalchardet : juniversalchardet : 1.0.3 Open Apache-2.0, AFL-2.1 or GPL-2.0+ org.ccil.cowan.tagsoup : tagsoup : 1.2.1 Open Not Declared, Not Supported d3 2.9.6 Open BSD-3-Clause, Adobe com.adobe.xmp : xmpcore : 5.1.3 Open Apache-2.0, No Source License com.cybozu.labs : langdetect : 1.1-20120112 Open Apache-2.0, No Source License com.fasterxml.jackson.core : jackson-annotations : 2.9.6 Open Apache-2.0, No Source License com.fasterxml.jackson.core : jackson-core : 2.9.6 Open Apache-2.0, No Source License com.fasterxml.jackson.core : jackson-databind : 2.9.6 Open Apache-2.0, No Source License com.fasterxml.jackson.dataformat : jackson-dataformat-smile : 2.9.6 Open Apache-2.0, EPL-1.0, MIT com.googlecode.mp4parser : isoparser : 1.1.22 Open Not Provided, No Source License com.ibm.icu : icu4j : 62.1 Open Apache-2.0, LGPL-3.0+ com.pff : java-libpst : 0.8.1 Open Apache-2.0, No Source License com.rometools : rome-utils : 1.5.1 Open CDDL-1.1 or GPL-2.0- CPE com.sun.mail : gimap : 1.5.1 Open CDDL-1.1 or GPL-2.0- CPE com.sun.mail : javax.mail : 1.5.1 Open Not Declared, Apache-1.1, Sun-IP dom4j : dom4j : 1.6.1 Open MIT, No Source License info.ganglia.gmetric4j : gmetric4j : 1.0.7 Open Apache-2.0, No Source License io.dropwizard.metrics : metrics-ganglia : 3.2.6 Open Apache-2.0, No Source License io.dropwizard.metrics : metrics-graphite : 3.2.6 Open Apache-2.0, No Source License io.dropwizard.metrics : metrics-jetty9 : 3.2.6 Open Apache-2.0, No Source License io.dropwizard.metrics : metrics-jvm : 3.2.6 Open Apache-2.0, No Source License io.prometheus : simpleclient_common : 0.2.0 Open Apache-2.0, No Source License io.prometheus : simpleclient_httpserver : 0.2.0 Open CDDL-1.0, CDDL-1.1 or GPL-2.0-CPE javax.activation : activation : 1.1.1 Open CDDL-1.0 or GPL-2.0- CPE, Apache-2.0, CDDL-1.1 or GPL-2.0- CPE javax.servlet
