Jackson-databind is actually not such an old version. The problem with Jackson databind is that for deserialization it has just a blacklist of objects not to deserialize and it is impossible to maintain that blacklist uptodate. For version 3.0 they change to a whitelist approach it seems which will resolve those errors. Until then all future versions of databind based on a blacklist approach are vulnerable. BTW this is for all applications using that library. Spring security has put on top of that additional items on the blacklist so even if nexusiq shows a security issue with databind but you have introduced additional means (eg you or another have worked on the blacklist) to be less vulnerable - nexusiq can’t know. Btw this is also what they explain when you open the detail of the security assessment.
Then, it depends on how you deploy software such as solr in your enterprise environment and they risks related to that. Eg one could have introduced means as above. Most of the users usually don’t have direct access to Solr itself but through a custom application, so there is no “direct” attack possible. Finally, the absence of findings in the report does not mean an application is secure. > Am 04.01.2019 um 19:27 schrieb Gus Heck <gus.h...@gmail.com>: > > Hi Bob, > > Wrt licensing keep in mind that multi licensed software allows you to > choose which license you are using the software under. Also there's some > good detail on the Apache policy here: > > https://www.apache.org/legal/resolved.html#what-can-we-not-include-in-an-asf-project-category-x > > One has to be careful with license scanners, often they have very > conservative settings. I had to spend untold hours getting jfrog's license > plugin to select the correct license and hunting down missing licenses when > I finally sorted out licensing for JesterJ. (though MANY fewer hours than > if I had done this by hand!) > >> On Fri, Jan 4, 2019, 11:17 AM Bob Hathaway <robh32...@gmail.com wrote: >> >> 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 <robh32...@gmail.com> 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-1000031 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 <robh32...@gmail.com> >> 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, 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 >>>> >>> >>
