grype
grype copied to clipboard
Grype does not detect CVE-2023-3635 against okio-jvm-3.0.0.jar
What happened: Grype does not detect CVE-2023-3635 against okio-jvm-3.0.0.jar What you expected to happen: CVE-2023-3635 to be detected How to reproduce it (as minimally and precisely as possible): run grype against container with okio-jvm-3.0.0.jar Anything else we need to know?:
Environment:
-
Output of
grype version
: -
Application: grype Version: 0.63.0 Syft Version: v0.84.0 BuildDate: 2023-06-21T16:11:07Z GitCommit: ca79c2a753fa90e1166a0f78f6e57c43808ba0c9 GitDescription: v0.63.0 Platform: linux/amd64 GoVersion: go1.19.10 Compiler: gc Supported DB Schema: 5
-
OS (e.g:
cat /etc/os-release
or similar): Linux
Hi @navzen2000, thanks for the report. I am unable to reproduce this problem with the latest version of Grype:
tgerla@Timothys-MacBook-Pro-2 grype-1457 % grype okio-jvm-3.0.0.jar
✔ Vulnerability DB [no update available]
✔ Indexed file system /Users/tgerla/git/test/grype-1457
✔ Cataloged packages [1 packages]
✔ Scanned for vulnerabilities [1 vulnerabilities]
├── 0 critical, 1 high, 0 medium, 0 low, 0 negligible
└── 0 fixed
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
okio-jvm 3.0.0 java-archive CVE-2023-3635 High
tgerla@Timothys-MacBook-Pro-2 grype-1457 % grype version
Application: grype
Version: 0.65.2
Syft Version: v0.87.1
BuildDate: 2023-08-17T20:03:30Z
GitCommit: 51223cd0b1069c7c7bbc27af1deec3e96ad3e07d
GitDescription: v0.65.2
Platform: darwin/arm64
GoVersion: go1.19.12
Compiler: gc
Supported DB Schema: 5
tgerla@Timothys-MacBook-Pro-2 grype-1457 %
Do you mind upgrading to the latest version, and letting us know if you are still seeing the same result? Thanks!
It did not work for me
[ grype]$ grype version
Application: grype
Version: 0.65.2
Syft Version: v0.87.1
BuildDate: 2023-08-17T20:03:30Z
GitCommit: 51223cd0b1069c7c7bbc27af1deec3e96ad3e07d
GitDescription: v0.65.2
Platform: linux/amd64
GoVersion: go1.19.12
Compiler: gc
Supported DB Schema: 5
[ grype]$ grype okio-jvm-3.0.0.jar
✔ Vulnerability DB [no update available]
✔ Indexed file system
✔ Cataloged packages [ 1 packages]
✔ Scanned for vulnerabilities [0 vulnerabilities]
├── 0 critical, 0 high, 0 medium, 0 low, 0 negligible
└── 0 fixed
No vulnerabilities found
Can you run sha1sum on the jar file to make sure we are both working with the exact same thing?
tgerla@Timothys-MacBook-Pro-2 grype-1457 % sha1sum okio-jvm-3.0.0.jar
0ab5a73fa2ccb4a36b0b5c69fe10b16d0255bcf8 okio-jvm-3.0.0.jar
(I downloaded mine from https://repo1.maven.org/maven2/com/squareup/okio/okio-jvm/3.0.0/okio-jvm-3.0.0.jar)
sha1sum okio-jvm-3.0.0.jar
48950be1407b1dfae0bbc2fb9b4190d08f1d4bb6 okio-jvm-3.0.0.jar
It contains GzipSource.class
java -jar jd-cli-1.2.1.jar GzipSource.class 21:03:28.003 INFO com.github.kwart.jd.cli.Main - Decompiling GzipSource.class import java.io.EOFException; import java.io.IOException; import java.util.Arrays; import java.util.zip.CRC32; import java.util.zip.Inflater; import kotlin.Metadata; import kotlin.jvm.internal.Intrinsics; import okio.Buffer; import okio.BufferedSource; import okio.GzipSource; import okio.InflaterSource; import okio.RealBufferedSource; import okio.Segment; import okio.Source; import okio.Timeout; import org.jetbrains.annotations.NotNull;
As per Github commit of the fix, it went into okio/src/jvmMain/kotlin/okio/GzipSource.kt https://github.com/square/okio/commit/81bce1a30af244550b0324597720e4799281da7b
Hi @navzen2000, thanks. Where did you get that okio-jvm-3.0.0.jar that differs from mine? Can you provide a link or attach it? Thanks.
We built this from source directly.
Could you attach your build, so we can compare the contents? Thanks!
I do nor have access to build but I have attached the jar in question. okio-jvm-3.0.0.jar.zip
Thanks, that helps. I think the problem here is that in your build, the META-INF/MANIFEST.MF file contains a lot less information than the build from Maven. Your build only contains:
Manifest-Version: 1.0
Whereas the Maven build contains:
Manifest-Version: 1.0
Automatic-Module-Name: okio
Bnd-LastModified: 1635459848508
Bundle-ManifestVersion: 2
Bundle-Name: com.squareup.okio
Bundle-SymbolicName: com.squareup.okio
Bundle-Version: 3.0.0
Created-By: 14.0.2 (Azul Systems, Inc.)
Export-Package: okio;uses:="javax.crypto,kotlin,kotlin.annotation,kotl
in.collections,kotlin.jvm,kotlin.jvm.functions,kotlin.jvm.internal,ko
tlin.reflect,kotlin.sequences";version="3.0.0"
Import-Package: javax.crypto,javax.crypto.spec,kotlin,kotlin.annotatio
n,kotlin.collections,kotlin.comparisons,kotlin.coroutines,kotlin.coro
utines.intrinsics,kotlin.coroutines.jvm.internal,kotlin.io,kotlin.jvm
,kotlin.jvm.functions,kotlin.jvm.internal,kotlin.reflect,kotlin.seque
nces,kotlin.text
Private-Package: okio.internal
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-6.0.0.202110041835
The MANIFEST.MF has important info for us to determine vulnerabilities, in this case I believe it's specifically the Bundle-Name field. If you look at the NVD entry for the missing vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2023-3635#range-9412322) you can see that list of CPEs that match the vulnerability all look like cpe:2.3:a:squareup:okio:...
. We are getting "squareup:okio" from the MANIFEST.MF, which we can't extract from your build.
Perhaps your build process can be changed to include the appropriate bundle name in your manifest? I hope this helps! Let us know if you need anything else.
Thanks for explaining what do you look at when determining issues. I understand the point now. I would like to close this issue.
You are welcome!
@tgerla Just an afterthought that I would like to share here:-
The Bundle information that tools seeks in manifest is something that is not originally checked into the original source code repo:- https://github.com/square/okio/
Though it might be another case that maven central is adding this information when building the jar There might be different build planforms that might add their own own metadata while building jar from original source. Therefore, relying upon this information might not be the right thing to do, where it would only serve artifacts built by maven central.
Thank you, I will run this by the team!