For security researchers, there is a series of hurdles in raising a potential vulnerability well before the issue itself is widely recognized. Convincing the project maintainers that there is an issue becomes the first hurdle, even with a working example.

At times, there is a thin and fuzzy line to a vulnerable path being identified as a bug rather than a security vulnerability. The reverse is also possible where a reported vulnerability is moved to being a bug even though it was utilized as an attack vector.

A good example is the vulnerability disclosure that DeveloperSteve tracked from the PHP core language around a Use After Free vulnerability type identified in the concat() function. It was demonstrated in a capture the flag event. The team reported the security issue only to have the report moved to a bug several posts later, irrespective of the vulnerability being utilized.

I recently went through the CVE process for the dompdf library incident, which only added to the incident timeline spanning 7 months. It continues to add to my appreciation for the work behind the nuances of getting a CVE published.

It's important to note here that many open source projects like this one are run and contributed to by passionate people, many of whom also work full-time and face the same pressures we all face daily while managing large-scale projects like this.

Let’s look at the incident timeline.

Understanding dompdf incident reporting timeline

As part of the public disclosure by Positive Security in March 2022, they also released the timeline leading up to disclosure.

The initial report with the project maintainers happened in October of 2021, this was raised using the project's security report page process. After months of no response, the Positive Security team tried escalating it as a bug on the repository.

This eventually led to a fixed version being pushed out after the public disclosure for the vulnerability. Adding to this incident, DeveloperSteve was able to leverage the vulnerable path to create the conditions for a reverse shell to be created. 

This is demonstrated in Snyk’s own Snyk-Labs PHP-Goof application, which features the original vulnerability upon which DeveloperSteve added PHP-related security vulnerabilities.

Using all the previous research and the reverse shell proof-of-concept code examples, DeveloperSteve was able to get a CVE for the incident 7 months after the initial report. 

Understanding the CVE process

Having recently gone through the CVE process, we now have a greater understanding and appreciation for security researchers' work in raising vulnerabilities. 

DeveloperSteve submitted a CVE request to Mitre, including all the original research, which is currently pending further analysis. This vulnerability has also been added as an example of the PHP-Goof demo application.

In a recently used example, a Use After Free vulnerability type was reported by a researcher in January. It was listed on Snyk’s vulnerability pages and identified as CVE-2021-21708.

Requesting a CVE

Initially, this process seemed easy enough, submit a web form and wait for someone to validate the findings. Heading over to the CVE.org report/request page, DeveloperSteve discovered that there’s a bit of a process before you get to submission. 

The first step of the process is identifying the CVE partner organization authorized to reserve and publish CVEs associated with the vulnerability being reported. These organizations are known as CVE Number Authorities or CNA. 

An organization that is listed as a CNA is allowed to triage security vulnerabilities and then reserve and publish CVE identifiers for reported security disclosures.

For example, in 2021, Snyk took on responsibility for Node.js ecosystem vulnerability disclosure program. As such, Snyk is a CNA and regularly publishes CVE security reports for numerous ecosystems, such as npm.

Note: Snyk has an easy-to-follow vulnerability disclosure form to report security vulnerabilities.

Conclusions on CVE reporting

There are times when there's a fuzzy line between a reported vulnerable path being determined to be a bug and not a vulnerability. Additionally, there are instances where a reported bug causes a vulnerable path and is actually a security threat. 

Beyond the initial security bug vs. issue being discovered by the community, security researcher, or contributor, there is the investigation phase, where the raised issue is further explored. Quite often, a malicious actor uses bugs as an attack vector to inject unwanted behavior into an application and/or infrastructure. 

At Snyk, the security team is dedicated to uncovering security vulnerabilities in their early inception as bug reports, even before they are made official CVEs. This commitment by Snyk helps keep our users secure and informed as early as possible.