Browse Prior Art Database

Automating correlating CVE numbers to file checksums

IP.com Disclosure Number: IPCOM000241746D
Publication Date: 2015-May-27
Document File: 3 page(s) / 68K

Publishing Venue

The IP.com Prior Art Database

Related People

Armijn Hemel: AUTHOR

Abstract

Security bugs are often reported in the form of CVE reports (Common Vulnerabilities and Exposures). These reports contain information about vulnerabilities and vulnerable packages, but a mapping to individual source code files and their cryptographic hashes (checksums) is often missing.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Automating correlating CVE numbers to file checksums

Security bugs are often reported in the form of CVE reports (Common Vulnerabilities and Exposures)
[1]. These reports contain information about vulnerabilities and vulnerable packages, but a mapping to individual source code files and their cryptographic hashes (checksums) is often missing.

Tags

Linux, FreeBSD, *BSD, Unix, QNX, Solaris, Android, Java, software, software development, security, defect discovery, reverse engineering, cve

Detailed description:

CVE (Common Vulnerabilities and Exposures) is a standard for security information[1]. The so called "CVE reports" contain information about vulnerabilities and exposures in a standard format, containing both structured and unstructured (free text) information. Each report is assigned a unique number ("CVE id") which can be referred to.

Information contained are a date, references to public sources (mailinglists, announcements, version control repositories with fixes, references to other vulnerability databases, etcetera), vulnerable packages and versions, impact severity of the bug, and so on, as well as a summary, which contains a description of the bug and is meant for processing by humans, while a lot of the other information is meant to be processed programmatically.

What is notably absent in CVE reports are cryptographic hashes or checksums of vulnerable files. While in some cases this is not possible because of the nature of the bug (no source code available because it is closed source, the problem is in a configuration, and so on) it is useful when there is source code available and the bug can be clearly linked to source code files. Having checksums available would allow for quickly checking code releases for the possible presence of security bugs or for finding packages that contain the security bugs mentioned in a CVE report but which were not mentioned in the list of vulnerable packages.

The method described in this document combines data from the publicly available CVE reports and data obtained from publicly availab...