Please add OWASP Dependency Check to the build (pom.xml) [SPR-17135]

[spring-projects-issues]

A Baker III opened SPR-17135 and commented

Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to perform a lookup for each dependant .jar to list any/all known vulnerabilities for each jar. This step is needed because a manual MITRE CVE lookup/check on the main component does not include checking for vulnerabilities in components or in dependant libraries.

OWASP Dependency check : https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most Java build/make types (ant, maven, ivy, gradle).

Also, add the appropriate command to the nightly build to generate a report of all known vulnerabilities in any/all third party libraries/dependencies that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false clean aggregate

Generating this report nightly/weekly will help inform the project's development team if any dependant libraries have a reported known vulnerailities. Project teams that keep up with removing vulnerabilities on a weekly basis will help protect businesses that rely on these open source componets.

---

Affects: 4.3.19, 5.0.9, 5.1 RC2, 5.1 GA

[spring-projects-issues]

Juergen Hoeller commented

I don't see this as applicable at the core framework level here since almost all of our dependencies are optional and express a compile-time minimum level, not necessarily a specific dependency version to use at runtime. Such a check seems a better fit at Spring Boot level where actual application-level dependency versions are being managed.

Stéphane Nicoll, what's your take on this?

[spring-projects-issues]

A Baker III commented

I added OWASP Dependency Check to Spring-Boot locally.     OWASP Dependency Check identified 5 dependent libraries with High severity issues and 14 dependent libraries with Medium Severity Issues.   This is typical of all open source components.

One library 

spring-data-solr-4.0.1.RELEASE.jar   has 5 high severity CVEs against it

cpe:/a:pivotal_software:spring_framework:4.0.1spring-data-solr-4.0.1.RELEASE.jar cpe:/a:pivotal_software:spring_framework:4.0.1cpe:/a:pivotal:spring_framework:4.0.1 org.springframework.data:spring-data-solr:

https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cpe_version=cpe%3A%2Fa%3Apivotal_software%3Aspring_framework%3A4.0.1
CVE-2018-1272   CVSS Severity = 7.5Spring Framework, versions 5.0 prior to 5.0.5 and versions 4.3 prior to 4.3.15 and older unsupported versions, provide client-side support for multipart requests. When Spring MVC or Spring WebFlux server application (server A) receives input from a remote client, and then uses that input to make a multipart request to another server (server B), it can be exposed to an attack, where an extra multipart is inserted in the content of the request from server A, causing server B to use the wrong value for a part it expects. This could to lead privilege escalation, for example, if the part content represents a username or user roles.
CVE-2018-1270   CVSS Severity = 9.8Spring Framework, versions 5.0 prior to 5.0.5 and versions 4.3 prior to 4.3.15 and older unsupported versions, allow applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a remote code execution attack.
CVE-2016-5007   CVSS Severity = 7.5Both Spring Security 3.2.x, 4.0.x, 4.1.0 and the Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x rely on URL pattern mappings for authorization and for mapping requests to controllers respectively. Differences in the strictness of the pattern matching mechanisms, for example with regards to space trimming in path segments, can lead Spring Security to not recognize certain paths as not protected that are in fact mapped to Spring MVC controllers that should be protected. The problem is compounded by the fact that the Spring Framework provides richer features with regards to pattern matching as well as by the fact that pattern matching in each Spring Security and the Spring Framework can easily be customized creating additional differences.

CVE-2015-5211  CVSS Severity = 9.3Under some situations, the Spring Framework 4.2.0 to 4.2.1, 4.0.0 to 4.1.7, 3.2.0 to 3.2.14 and older unsupported versions is vulnerable to a Reflected File Download (RFD) attack. The attack involves a malicious user crafting a URL with a batch script extension that results in the response being downloaded rather than rendered and also includes some input reflected in the response.
CVE-2014-0225   CVSS Severity = 8.8When processing user provided XML documents, the Spring Framework 4.0.0 to 4.0.4, 3.0.0 to 3.2.8, and possibly earlier unsupported versions did not disable by default the resolution of URI references in a DTD declaration. This enabled an XXE attack.

 

This is the /type/ of information that the OWASP report can provide.   After running the report, its simple to look for newer jar, and update the pom.   

 

The thing is, this is something that the Dev team should do in the product, not have every dev shop mainatin this stuff.

[spring-projects-issues]

A Baker III commented

Another example from the same report......  

signalfx-java-0.0.48.jar (shaded: com.fasterxml.jackson.core:jackson-databind:2.2.2) cpe:/a:fasterxml:jackson:2.2.2signalfx-java-0.0.48.jar (shaded: com.fasterxml.jackson.core:jackson-databind:2.2.2) cpe:/a:fasterxml:jackson:2.2.2cpe:/a:fasterxml:jackson-databind:2.2.2 com.fasterxml.jackson.core:jackson-databind:
https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cpe_version=cpe%3A%2Fa%3Afasterxml%3Ajackson-databind%3A2.2.2

****** 2.9.7 is out = create a Jira Ticket to upgrade 

CVE-2018-7489  V3: 9.8 CRITICALFasterXML jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 libraries are available in the classpath.

CVE-2017-7525   V3: 9.8 CRITICALA deserialization flaw was discovered in the jackson-databind, versions before 2.6.7.1, 2.7.9.1 and 2.8.9, which could allow an unauthenticated user to perform code execution by sending the maliciously crafted input to the readValue method of the ObjectMapper.

CVE-2017-15095    V3: 9.8 CRITICALA deserialization flaw was discovered in the jackson-databind in versions before 2.8.10 and 2.9.1, which could allow an unauthenticated user to perform code execution by sending the maliciously crafted input to the readValue method of the ObjectMapper. This issue extends the previous flaw CVE-2017-7525 by blacklisting more classes that could be used maliciously.

CVE-2018-5968   V3: 8.1 HIGHFasterXML jackson-databind through 2.8.11 and 2.9.x through 2.9.3 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 and CVE-2017-17485 deserialization flaws. This is exploitable via two different gadgets that bypass a blacklist.

CVE-2017-17485   V3: 9.8 CRITICALFasterXML jackson-databind through 2.8.10 and 2.9.x through 2.9.3 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the Spring libraries are available in the classpath.

 

I spent the Summer having Apache projects add the OWASP Dependency Plugin.   They /almost/ all noe include it.    Spring should too.

[spring-projects-issues]

Andy Wilkinson commented

My experiences with automated dependency checks using the OWASP Dependency Plugin have, unfortunately, all been negative. Here is one example and here is another. I would not recommend adding it to Spring Framework and I am not in favour of adding it to Spring Boot's build either. For Spring Boot, we already have a process in place for keeping the versions of our managed dependencies up-to-date using Bomr.

[spring-projects-issues]

A Baker III commented

I understand your concern. The problem is that it only takes one high severity issue to compromise a system.  I'm a consultant, my customers include banking/finance, medical, and critical infrastructure.  They will not allow a system to be deployed that has one high severity CVE.   If OWASP Dependency check (or any other) has 50% fals positives, its still better to flag and mitigate the 50% that are real problems.   Youcalim you dont have the time, but you care about security....hmmmm.   So if your 401k id gotten to, or the hospital where /your/ child is having surgery at, or the natural gas pipeline that feed your house is messed with....  that one high severity issue becomes more important.  Half of the Apache projects have implemented OWASP dependency check(warts and all) and are building acceptable quality products now.   I have built the spring-boot report and and am assesing the severity of the issues.   Mostly the issues are easily fixed by simply upping the version of a jar in the pom.  Its not a hard lift.    I am wonding the last time you ran Bomr.  Many of the jars in spring boot are old and I know for a fact that many are true vulnerabilities.   I will start posting individual Jira tickets to upgrade jar versions shortly.

[spring-projects-issues]

Andy Wilkinson commented

This is really off-topic for a Spring Framework issue, but we run Bomr at least once prior to every release of Spring Boot. Some dependencies in 1.5.x and 2.0.x are not the latest available, but please note that we only upgrade to new maintenance releases of a dependency in a maintenance release of Spring Boot. Similarly, we generally only upgrade to new major version of a dependency in a major version of Spring Boot, although we occasionally move to a new major version of a dependency in a minor version of Spring Boot. Users are, of course, free to override our managed dependencies where compatible to meet their specific needs.

[spring-projects-issues]

Stéphane Nicoll commented

Thanks, I share that feeling and I am not keen to add this to the build. We are very actively monitoring the ecosystem and take action using bomr as Andy indicated.

[spring-projects-issues]

A Baker III commented

All :   Very impressive work with 5.1.3 !!!!!!!      Up till that release, I was not impressed. 

Comparing the reports :

5.1.0 :
Dependencies Scanned: 61 (61 unique)
Vulnerable Dependencies: 9
Vulnerabilities Found: 110

5.1.2:
Dependencies Scanned: 61 (61 unique)
Vulnerable Dependencies: 11
Vulnerabilities Found: 112       

<Vulnerabilities went up, 2 newly reported issues, no culling of previously known issues>

5.1.3:
Dependencies Scanned: 104 (99 unique)
Vulnerable Dependencies: 6
Vulnerabilities Found: 9

WOW !!!!!!

Latest version added +50% more jars (either to the project or are now ? scannable> - thats more complexity & more attack surface

But raw # of Vulnerable dependencies got cut almost in half.

AND raw number of vulnerabilities found(irrespective of possible false positive count) is less than one/tenth of what it was in the last rev.

That is excellent work.  Thank You !!!!!!!!!