jpopelka
commented
6 years ago There are several ideas from where we can possibly get these mappings. Few can be taken from 'downstreams', some from existing vulnerability databases like VictimsDB which licenses the data under CC-BY-SA. I'll leave these out for now and focus on getting the mappings from CVE texts. As I described in (C) a CVE usually contains a CPE and several references (URLs). If we follow the references, we can (with help of vendor:product from CPE) eventually find out what package_manager:package_name (if any) the CVE affects. Once we have the package_manager:package_name to vendor:product mapping, we can reliably search data from NVD for vulnerabilities in the analysed package.
For some references it's easier to find out the package_manager:package_name.
One usually first tries to find out what language is the product written in and then search related package manager portal (like https://www.npmjs.com for javascript).
Or if the reference leads to a source code repository (like github), then it's usually quite easy to find out the language. Also the readme can contain install instructions like [npm/pip] install <package> in which case we're done.
Sometimes the references point to various mailing lists, bug/issues trackers - in these cases we can't say what to look for or how to decide whether the component is shipped by any package manager. In such cases the only way is to just search the vendor:product on internet.
For manual CVE texts 'scanning' we can use www.cvedetails.com, which has nice UI. For (semi-)automatic scanning we'd probably use data from NVD.
A manual step-by-step how to find out some mapping from CVE would be:
- select month in Vulnerabilities By Date
- select CVE
- if Products Affected By is empty, skip this CVE
- go through References and try to find a homepage or source code repository of the product
- check install instructions in readme
- find out what language is the product written in (for example github has language stats) and search related package manager portal (https://pypi.python.org for Python, https://www.npmjs.com for javascript, http://mvnrepository.com for java, https://www.nuget.org for .NET)
- if found, add package-identifier -> vendor:product mapping to database of mappings
Examples:
Pypi (python)
- September 2017
- CVE-2017-1002150
- affected vendor:product is Fedoraproject:Python-fedora
- follow https://github.com/fedora-infra/python-fedora in resources
- language stats says it's Pythonu and searching pypi reveals https://pypi.python.org/pypi/python-fedora
- new mapping is
pypi:python-fedora -> fedoraproject:python-fedora - now we're able to search NVD data for
pypi:python-fedorapackage by actually searching forfedoraproject:python-fedora, for example via cve.circl.lu: https://cve.circl.lu/api/cvefor/cpe:2.3:a:fedoraproject:python-fedora:0.8.0
Npm (nodejs)
- Security Vulnerabilities Published In April 2017
- go to page 30
- CVE-2015-7565
- affected vendor:product is Emberjs:Ember.js
- First reference leads to https://emberjs.com where I see
npm install -g ember-cli - package identifier therefore is npm:ember-cli
- mapping is
npm:ember-cli -> emberjs:ember.js - verify https://cve.circl.lu/api/cvefor/cpe:2.3:a:emberjs:ember.js:1.10.1
Nuget (.NET)
- CVE-2017-0247
- affects multiple products
- Microsoft as a Vendor suggests this might be a nuget package manager, so it's just a matter of confirming that each product can be found on nuget.org
- for example System.net.security is on nuget.org as System.Net.Security so we are free to add
nuget:System.Net.Security -> microsoft:system.net.securitymapping
- for example System.net.security is on nuget.org as System.Net.Security so we are free to add
- verify https://cve.circl.lu/api/cvefor/cpe:2.3:a:microsoft:system.net.security:4.0.0
Maven (java)
- Security Vulnerabilities Published In April 2017
- go to page 8
- CVE-2017-5662
- affected vendor:product is Apache:Batik
- second reference leads us to https://xmlgraphics.apache.org/batik
- projects on apache.org are usually java, but the page does not explicitly say so, so all we can do is to ask google
- first link leads to https://mvnrepository.com/artifact/org.apache.xmlgraphics/batik-svggen/1.7, which really is one of the batik components, but there are many others and the question is whose of them are affected by the CVE ?
- Snyk.io claims it's batic-dom, while Victims says it's batic-rasterizer
- since in this task we are not interested in CVEs, but just creating a mapping from one identifier to another, we can add
maven:org.apache.xmlgraphics/batik-<submodule> -> apache:batikfor each<submodule>on the page
- verify https://cve.circl.lu/api/cvefor/cpe:2.3:a:apache:batik:1.8
More maven (java)
- CVE-2017-5929
- reference leads to https://logback.qos.ch and again the question whether this product is packaged by any package manager is a matter of searching via google, which eventually leads to https://mvnrepository.com/artifact/ch.qos.logback
- result are mappings
maven:ch.qos.logback/logback-<submodule> -> logback:logbackfor each<submodule>on the page
Trying to find out a package_manager:package_name from the CVE references might be quite difficult in some cases (like the java examples, where it's hard to find out that the product is actually in java and then finding correct components in mvnrepository) and hence time consuming. Also in most cases the affected vendor:product isn't shipped by any package manager, therefore does not lead to any useful mapping.
msrb
Description
In #1052 we agreed on that if we want to build a source of open data with vulnerabilities we should start with creating a mappings of package identifiers (i.e a string that we use to identify a package) to CPEs (i.e. to what NVD uses to identify product) in order to be able to reliable search data from NVD database for vulnerabilities in packages that we analyse.
Now we want to take the most viable idea and start putting it into actual steps how to proceed. Having these steps we will continue in #1260
Acceptance criteria: