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...