DependencyCheck
DependencyCheck copied to clipboard
jeremylong
[FP]: CVE-2022-31569 [email protected] & javax.jms-api-2.0
Package URl
pkg:maven/jakarta.annotation/[email protected], pkg:maven/javax.jms/[email protected]
CPE
cpe:2.3:a:oracle:java_se:1.3.5:*:*:*:*:*:*:*, cpe:2.3:a:oracle:projects:1.3.5:*:*:*:*:*:*:*, cpe:2.3:a:projects_project:projects:1.3.5:*:*:*:*:*:*:*
CVE
CVE-2022-31569
ODC Integration
{"label"=>"Gradle Plugin"}
ODC Version
7.1.1
Description
overly inclusive CPE? https://nvd.nist.gov/vuln/detail/CVE-2022-31569 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31569
We hit the same thing (including CVE-2022-31548 )
[ERROR] jakarta.annotation-api-1.3.5.jar: CVE-2022-31569(9.3)
[ERROR] jakarta.transaction-api-1.3.3.jar: CVE-2022-31569(9.3)
[ERROR] querydsl-core-5.0.0.jar: CVE-2022-31548(9.3)
[ERROR] spring-cloud-commons-3.1.3.jar: CVE-2022-31569(9.3)
[ERROR] spring-security-rsa-1.0.10.RELEASE.jar: CVE-2022-31569(9.3)
These CVE descriptions both seem to reference github repositories
The RipudamanKaushikDal/projects repository through 2022-04-03 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely.
and
The nrlakin/homepage repository through 2017-03-06 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely.
Has anyone else noticed the quality of the CVEs has gone down recently? There was a CVE for a documentation bug recently (in some example code!).
This seems a bit extreme and if, like us, it breaks the build it generates a lot of effort.
We got the same issue on javax.jms-api-2.0.1.jar: CVE-2022-31569(9.3) stax-ex-1.8.3.jar: CVE-2022-31569(9.3)
Same problem here.
- jakarta.annotation-api-1.3.5.jar: CVE-2022-31569(9.3)
- jakarta.transaction-api-1.3.3.jar: CVE-2022-31569(9.3)
- spring-data-jpa-2.7.1.jar: CVE-2022-31569(9.3)
It looks like all these projects have "projects" in their url-Tag. Is there a reason why the url is used for matching CVEs?
Doesn't sounds logical to me in the first place...
An addition to the dependencies mentioned above.
- jts-1.13.jar: CVE-2022-31569(9.3)
- murmur-1.0.0.jar: CVE-2022-31569(9.3)
- spring-data-redis-2.7.1.jar: CVE-2022-31569(9.3)
It will probably affect a lot of projects unfortunately.
more dependencies:
- de.intarsys.opensource:jbig2_5.5.1 - CVE-2022-31548
- jakarta.servlet:jakarta.servlet-api:4.0.4 - CVE-2022-31569
Hello, a few more false positive regarding CVE-2022-31569:
- vecmath-1.5.2.jar (pkg:maven/javax.vecmath/[email protected], cpe:2.3:a:projects_project:projects:1.5.2:::::::*) : CVE-2022-31569
- annotations-4.1.1.4.jar (pkg:maven/com.google.android/[email protected], cpe:2.3:a:projects_project:projects:4.1.1.4:::::::*) : CVE-2022-31569
- timingframework-core-7.3.1.jar (pkg:maven/net.java.timingframework/[email protected], cpe:2.3:a:projects_project:projects:7.3.1:::::::*) : CVE-2022-31569
Looking at the github repo referred in the CVE https://github.com/RipudamanKaushikDal/projects, I wonder if we should not suppress this CVE altogether.
The CVE is based on https://github.com/RipudamanKaushikDal/projects/issues/21 and I wonder since they seem to be example projects, that the security issue will be fixed.
Hello, a few more false positive regarding:
- jakarta.annotation-api-1.3.4.jar (pkg:maven/jakarta.annotation/[email protected], cpe:2.3:a:oracle:projects:1.3.4:::::::, cpe:2.3:a:projects_project:projects:1.3.4:::::::) : CVE-2022-31569
- wsdl4j-1.6.3.jar (pkg:maven/wsdl4j/[email protected], cpe:2.3:a:projects_project:projects:1.6.3:::::::*) : CVE-2022-31569
Affecting also:
jakarta.jms-api-2.0.3.jar (pkg:maven/jakarta.jms/[email protected], cpe:2.3:a:projects_project:projects:2.0.3:*:*:*:*:*:*:*) : CVE-2022-31569
spring-hateoas-1.5.1.jar (pkg:maven/org.springframework.hateoas/[email protected], cpe:2.3:a:projects_project:projects:1.5.1:*:*:*:*:*:*:*) : CVE-2022-31569
We've got the same problem for Spring artifacts, and it seems that the CVE is actually for Python which is not used in the project 🤦
See https://github.com/spring-projects/spring-boot/issues/31776.
CVE-2022-31569 is now failing on these dependencies:
[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0':
[ERROR]
[ERROR] jakarta.annotation-api-1.3.5.jar: CVE-2022-31569(9.3)
[ERROR] jakarta.transaction-api-1.3.3.jar: CVE-2022-31569(9.3)
These jakarta artifacts are coming from the following Spring dependencies:
| +- org.springframework.boot:spring-boot-starter:jar:2.7.1:compile
| | +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile
+- org.springframework.boot:spring-boot-starter-data-jpa:jar:2.7.1:compile
| +- jakarta.transaction:jakarta.transaction-api:jar:1.3.3:compile
Is it safe to assume then that these are false positives? Any idea on how their suppression rules would look like?
@lackovic
This is an example of the suppression file to ignore this CVE:
<?xml version="1.0" encoding="UTF-8"?>
<!--
An advice from https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-1132621725
-->
<!--
Documentation: https://jeremylong.github.io/DependencyCheck/general/suppression.html
-->
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
<!-- Known FP, see https://github.com/jeremylong/DependencyCheck/issues/4671 -->
<suppress>
<notes><![CDATA[Ignored since it is a known false-positive]]></notes>
<packageUrl regex="true">^pkg:maven/jakarta.*$</packageUrl>
<cve>CVE-2022-31569</cve>
</suppress>
</suppressions>
And this is how to set the ignore file in Maven plugin settings:
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>${dependency-check-maven.version}</version>
<configuration>
<suppressionFile>${project.build.outputDirectory}/dependency-check-suppress.xml</suppressionFile>
...
FWIW, we got false positives in other libraries too, including JUnit 5 1.9.0 RC1. The exclusion list is this so far, false positives refer to Python projects using Flask send_file and are completely unrelated to Java anyway. CVEs mention RipudamanKaushikDal/projects repository (CVE-2022-31569) and Caoyongqi912/Fan_Platform (new, CVE-2022-31514) only so far, but as I get it, there might be a chance of getting 90 more such CVEs possibly. The first of these appeared on Friday, today our list has grown to this, builds failing in several projects. Reason behind all this seems to be a long list of Python projects with send_file path traversal problems. @see https://github.com/github/securitylab/issues/669
<suppress>
<notes><![CDATA[
file name: jakarta.annotation-api-1.3.5.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/jakarta\.annotation/jakarta\.annotation\-api@.*$</packageUrl>
<cve>CVE-2022-31569</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: cardme-0.4.0.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/net\.sourceforge\.cardme/cardme@.*$</packageUrl>
<cve>CVE-2022-31569</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-engine-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-engine@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-suite-engine-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-suite\-engine@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-commons-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-commons@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-launcher-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-launcher@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-suite-api-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-suite\-api@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
<suppress>
<notes><![CDATA[
file name: junit-platform-suite-commons-1.9.0-RC1.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.junit\.platform/junit\-platform\-suite\-commons@.*$</packageUrl>
<cve>CVE-2022-31514</cve>
</suppress>
Scanner plugin is latest 7.1.1 everywhere.
As I pointed out in #4675, I believe the RipudamanKaushikDal/projects repo is the main culprit, matching an overly generic name "projects". In our project at work, we use a dependency that happens to be created by the Android project, which causes this to match:
<evidence type="vendor" confidence="MEDIUM">
<source>pom</source>
<name>developer name</name>
<value>The Android Open Source Projects</value>
</evidence>
this broke all Java builds on all projects across our entire company. Everyone is madly adding suppressions this morning in every git repo. Please mark this one as urgent, thank you
Even after using the suppressions above, I am still getting the following:
Error: One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '7.0': Error: spring-cloud-commons-3.1.3.jar: CVE-2022-31569(9.3)
Am I missing something?
Even after using the suppressions above, I am still getting the following:
Error: One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '7.0': Error: spring-cloud-commons-3.1.3.jar: CVE-2022-31569(9.3)
Am I missing something?
You don't need to add "all" the suppressions above, just the ones you got the warnings for. Specifically, for spring-cloud-commons-3.1.3.jar, you need to add (with one month expiration time) something like this:
<suppress until="2022-08-18Z" base="true">
<notes><![CDATA[ FP per issue #4671 ]]></notes>
<packageUrl regex="true">^pkg:maven/spring-cloud-commons.*$</packageUrl>
<cve>CVE-2022-31569</cve>
</suppress>
Since these are stupid CVEs (and very explicit) we exclude using a match everything pattern.
<suppress>
<notes><![CDATA[
file name: jakarta.annotation-api-1.3.5.jar,jakarta.transaction-api-1.3.3.jar,spring-cloud-commons-3.1.3.jar,spring-security-rsa-1.0.10.RELEASE.jar,querydsl-core-5.0.0.jar
The RipudamanKaushikDal/projects repository through 2022-04-03 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely
reason: We do not use Github
]]></notes>
<packageUrl regex="true">^.*$</packageUrl>
<cve>CVE-2022-31569</cve>
<cve>CVE-2022-31548</cve>
</suppress>
We're using this suppression, which should be general-purpose enough for anyone:
<suppress>
<notes><![CDATA[
These CVEs are actually about a random personal repository
containing several projects, "RipudamanKaushikDal/projects", and
this gets triggered because annotations is by a developer called
"The Android Open Source Projects"...
]]></notes>
<cpe>cpe:2.3:a:projects_project:projects:*:*:*:*:*:*:*:*</cpe>
<cve>CVE-2022-31569</cve>
</suppress>
IMO we do not need to take any action as the CVE is now rejected: https://nvd.nist.gov/vuln/detail/CVE-2022-31569#VulnChangeHistorySection
That may be true, but CVE-2022-31514 for instance is not.
True, sorry. What a mess this guy created...sigh.
That may be true, but CVE-2022-31514 for instance is not.
True, sorry. What a mess this guy create...sigh.
The CVE process is surprisingly ill-prepared to deal with "security researchers" trying to pad their CVs... This has been becoming a bigger problem in recent years.
Well, the GitHub Security Lab is official and no corner shack, and I wouldn't question their expertise or good intentions in the least. But there is obviously something wrong somewhere if suddenly Python security issues in some obscure private projects lead to a flood of level 9+ security issues in completely unrelated Java libraries, breaking builds all over the world and wasting endless engineer hours for nothing to fix them again. Maybe it's MITRE or nist.gov, who knows. We've seen comparable things with version ranges recently, for example with spring-security-crypto (CVE-2020-5408, seems corrected now) where the issue was long fixed in 5.7.x but scanners (including SonaType OSSIndex) flagged it anyway. Or Apache Tika 2.4 (CVE-2022-25169) where the reporter submitted everything correctly but someone still got the CPE wrong, including the fixed version as well. In these cases, though, there was an actual Java lib flaw behind it worth looking into.
Despite other folks and myself reaching out to NIST asking them to re-evaluate (and reject) a pile of those bogus CVEs this has thus far only happened for CVE-2022-31569.
CVE-2022-31514 for example is still a major headache and I am wondering if the maintainers @jeremylong and @aikebah have a proposal as for how to proceed. For now we suppress them ourselves (company-wide) with a rule like here https://github.com/jeremylong/DependencyCheck/issues/4671#issuecomment-1188617739.
This is unfortunately one of the issues with the evidence based library identification process used by dependency-check. Without a major re-work of ODC the best that can be done is to put a broad bandaid in place when things like this occur in the data sources used. Something like the proposed suppression rule in https://github.com/jeremylong/DependencyCheck/issues/4671#issuecomment-1188617739.
I swear to God if they start issuing CVEs for forks of repositories I'm going to quit. 😆
I do have a clone porcupineyhairs/MercadoEnLineaBack which has been included in the LGTM run I shared earlier. As for the forks, scaraude/Piano-LED-Visualizer and Nbobito/Piano-LED-Visualizer, these are forks of onlaj/Piano-LED-Visualizer but have divereged from the original repo. They should be treated as separate projects but I haven't sought a CVE for them and I haven't included them in the LGTM run.
https://github.com/github/securitylab/issues/669#issuecomment-1189426814
I swear to God if they start issuing CVEs for forks of repositories I'm going to quit. 😆
In particular as that Piano LED visualizer is a Raspberry Pi maker project enabling you to learn songs from MIDI scores via blinkenlights on your piano. It runs on a Pi (Zero) and ok, has a web interface, but by definition, that Pi has to reside beside your keyboard when playing, otherwise it makes no sense at all. It is very very unlikely that Pi will ever be connected to anything else than maybe your local WLAN at home, and you wouldn't install that software anyway if you haven't tinkered together the various hardware components required before which I absolutely doubt too many people would do. So, IMHO the risk even of the dreaded path transversal attack here is minimal and something you can contact the author about, but certainly not nist.gov even if he keeps silent.
In particular as that Piano LED visualizer is a Raspberry Pi maker project enabling you to learn songs from MIDI scores via blinkenlights on your piano
@cbollmeyer Ha! Everyone hurry up and patch!!! The data that controls the blickity lights for your piano is at risk of a traveral attack 🤣 🤣
I give up! I say merge https://github.com/jeremylong/DependencyCheck/pull/4688 I tried to fight the good fight.
Per MITRE -
So, for example, you have proposed to reject CVE-2022-31577 but we are not proceeding with any rejections at this time. People can use this "audio_aligner_app" software for their own purposes, and others have already forked the GitHub repository and might be doing that. However, the property of "unless you are supplying your own development resources, you would have no practical way to use this software" may well be applicable. Furthermore, Mission Prevalence would most likely have a value of Minimal. In other words, there would be at least two separate dimensions through which people could make a judgment that CVE-2022-31577 is less important than most other CVE Records. We feel that this approach is better than rejecting a CVE Record, because that suggests that a central authority can make a definitive declaration that the software is never used or there is never any risk.
This is one I tried to reject per https://github.com/github/securitylab/issues/669#issuecomment-1189337273. It actually had a license so the project is more useful than most, but there is only 4 commits on the repo.
https://github.com/LongmaoTeamTf/audio_aligner_app/commits/master
and most of it's screenshots, there is no usable code at all -
https://github.com/LongmaoTeamTf/audio_aligner_app/commit/77601a5b6a71391a0d9eb66d55ee821ab5f019c0#diff-5fd096f1e71fb904612a19f875ed9fbbb516ab93f1dbad423f95a359030d9375
Complete junk! Hopefully it can be weeded out.