Interpreting CPEs

[tinius.alex...@gmail.com]

Interpreting CPEs and figuring out if a file is correctly identified or not seems to be a bit of a challenge.


Starksoft.Net.Ftp.dll is identified by cpe:/a:ftp:ftp, which is probably incorrect. Future vulnerabilities in Starksoft.Net.Ftp.dll will probably be reported on another CPE. Easy enough.

Microsoft.SqlServer.Compact.4.0.8876.1.nupkg\Microsoft.SqlServer.Compact.nuspec is identified by cpe:/a:microsoft:sql_server:2008:r2_sp1:itanium, which seems clearly incorrect. However, the same file is also identified by cpe:/a:microsoft:server:4.0.0.0. How do I tell if this is correct?

In some instances I'm not only unsure if a file has been correctly identified (meaning the correct CPE has been found), but also if future vulnerabilities in my dependency might be reported/categorized on that CPE:

• Mono.Security.dll identified by http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Amono%3Amono

• NDbUnit.OracleClient.dll identified by http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Aoracle%3Aoracle_client

• NLog.2.1.0.nupkg identified by http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Anlog%3Anlog

How do you navigate these CPEs and determine if they are correct?

[colezlaw]

Unfortunately, sometimes navigating CPE's actually is difficult. CPE's have a common structure (bits of information that must be present), but there's not really any body that governs correctness or completeness of the data submitted from the vendors - e.g., Microsoft submits CPE's for their own products, and while what they submit is reviewed, it's often ambiguous.

This frequently happens with client libraries for server products. You'll see this with websphere client libraries, database drivers (as you see here), etc. While the driver itself is not necessarily vulnerable, if I'm not the developer, I tend to NOT suppress those - the client libraries can be a means by which we discover what the development teams are running on the server - which should also be updated.

In the case of NLog, the challenge here is that the Nuspec only has the package name (nlog) and the DLL reports the company name as NLog and the package name as NLog and the version as 2.1.0.0. This is the information that the vendor put in the assembly. If you look at the CVE mentioned, the CPE's that match that are cpe:/a:nlog:nlog - and any version. So this one is one that would need to be suppressed.

There's not currently a global suppression list, although I'm trying to figure out the best way to manage that - whether we deploy a known set of things like this that should simply globally be set, or if we can use other analyzers to limit it. I think that this maelstrom of false positives we're getting are primarily in .NET stuff, which is not surprising since the .NET analysis is brand new. We'll have to figure out some better ways to handle .NET stuff, but as of right now, for your specific questions, I don't have good answers except to use the suppression file, and *thank you* for pointing these out to us. The ability to make the findings more accurate is only improved by scanning MORE stuff and getting more intel back from the community.

[tinius.alex...@gmail.com]

If I ignore cpe:/a:nlog:nlog for these files, am I not risking ignoring future vulnerabilities in my NLog library (assuming the vulnerability could be reported on this CPE)?

[Jeremy Long]

Yes, suppressing the cpe:/a:nlog:nlog could produce false negatives in the future. For a case like this I would suggest suppressing the specific CVE. Only suppress the CPE if the actual match (vendor/product) is incorrect. Otherwise, suppressing specific CVE entries that don't apply is appropriate.

--Jeremy

--
You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-che...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.