The tool gave 7z.dll a clean go

[mikerabat]

In our project we provide an old version of the 7z.dll to compress decompress streams. The dll is provided in our applications program directory.

According to https://nvd.nist.gov/vuln/detail/CVE-2024-11477
there is a critical vulnarability but the command line tool gave it a pass.

The command line I used was:

dependency-check.bat --project "Darwin" --scan "C:\Program Files (x86)\Darwin2"

where Darwin2 is our Deskop application....

Is there anything I did wrong or is this test not in the database?

kind regards

[chadlwilson]

I didn't think ODC could scan arbitrary native DLLs - only .NET assemblies packaged as DLL where the metadata can be exracted. Is there an analyzer you'd expect to detect this? https://jeremylong.github.io/DependencyCheck/analyzers/

[mikerabat]

Actually it extracts only the file version and such from any exe/dll. The 7z dll we use is pretty old (9.20) which clearly should show the problem... Accoding to the Nist entry the vulnarabiliyt is up to version 24.07

[chadlwilson]

The NVD entry is irrelevant if the project has no mechanism to match a binary to a product enumeration and version from reliable metadata.

The question still applies as to which analyzer you expect to work, as i dont see anything documented that implies this might work.

[mikerabat]

First... sorry I'm new to that tool and was tasked to anaylze our binaries and dependencies...

I would have thought that the assembly-analyzer does the work using GrokAssembly.exe tool - which as far as I can see does it exactly that - extracting vendor and version information...

[chadlwilson]

Yeah, .NET assemblies are different in structure to unmanaged C/C++ DLLs (as 7zip is written in).

I might be wrong, but I don't think ODC does what you're looking for, and personally not aware of other tools that handle arbitrary Windows DLLs consistently, other than commercial ones which maintain their own databases.

[jeremylong]

You should take a look at https://jeremylong.github.io/DependencyCheck/general/internals.html

The documentation will explain how ODC works and why arbitrary DLLs are difficult to scan.

[mikerabat]

I don't see why it should be difficult - the version information is there ... so.. (still a beginner here) am I right assuming that the base problem is that the NVD vector on https://nvd.nist.gov/vuln/detail/CVE-2024-11477#range-16108449 that would be populated onCVSS Version 4.0 is actually not provided? The section "Known Affected Software Configurations" actually cover the affected version...

…

On Thu, Dec 26, 2024 at 5:17 PM Jeremy Long ***@***.***> wrote: You should take a look at https://jeremylong.github.io/DependencyCheck/general/internals.html The documentation will explain how ODC works and why arbitrary DLLs are difficult to scan. — Reply to this email directly, view it on GitHub <#7269 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACX47A5YKKNV5NT2VDAH7Z32HQT2HAVCNFSM6AAAAABUDISOO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRSHEZDIOJQGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeremylong]

look at the CPE, how is ODC supposed to go from 7z.dll to cpe:2.3:a:7-zip:7-zip:*:*:*:*:*:*:*:*? '7z' != '7-zip'. Where is the "version" information in 7z.dll?

We accept PRs...

[mikerabat]

I see... so you are saying that the main problem is that it states that the actual dll is not 7z.dll but rather 7-zip.dll is expected?

From a laymans perspective (who uses the tool the first time):
However the properties of the 7z.dll show "7-Zip" as "Product name" and the Version (e.g. 9.20 in my case) in the "Version field.
These fields are actually extracted by the GrokAssembly.exe tool via the standard windows api "GetVersionInfo" ... The list of matching CPEs also adds the specific version....

[jeremylong]

can you copy and paste the evidence section?

[OrangeDog]

Not OP, but I tested on the 7z.dll version I have:

Evidence

Vendor	file	name	7z	High
Vendor	PE Header	CompanyName	Igor Pavlov	Highest
Vendor	PE Header	LegalCopyright	Copyright (c) 1999-2023 Igor Pavlov	Highest
Product	file	name	7z	High
Product	PE Header	InternalName	7z	Medium
Product	PE Header	ProductName	7-Zip	Highest
Version	PE Header	FileVersion	23.01	High
Version	PE Header	ProductVersion	23.01	Highest

Identifiers

• pkg:generic/[email protected] (Confidence:Medium)
• cpe:2.3:a:igor_pavlov:7-zip:23.01:::::::* (Confidence:Low)

@mikerabat it should work if you add a hints.xml to override the Vendor to "7-zip".

[OrangeDog]

@jeremylong I've seen this sort of false negative a few times. Is it worth perhaps in general trying the Product as the Vendor if there are no CPE matches for the detected Vendor?

[jeremylong]

It looks like we need to enhance the assembly analyzer to add the Product Name as a lower-confidence item in the vendor bucket.

[OrangeDog]

@jeremylong as I said, I've seen this a few times before, and it's not just the assembly analyzer.

Sometimes CPEs just get allocated as <project>:<project>, especially when the "vendor" is a person and not a company.