Open-source vulnerability disclosure: Exploitable weak spots

Flaws in the vulnerability disclosure process of open-source projects could be exploited by attackers to harvest the information needed to launch attacks before patches are made available, Aqua Security researchers worry.

The risk arises from “half-day” and “0.75-day” vulnerabilities

“Half-day” vulnerabilities are known to the maintainer and information about them is publicly exposed on GitHub or the National Vulnerability Database, but there’s still no official fix.

“0.75-day” vulnerabilities have an official fix, but not a CVE number or a CPE identifier, which means that vulnerability scanning tools can’t detect the vulnerable component in the organizations’ environment and security teams are not aware they need to implement it.

“Attackers can harvest any indicators of a new vulnerability being formed or disclosed on public platforms (GitHub, NVD). Utilizing messages and meta-data found in pull requests, commits and issues the attackers can locate references to the vulnerable code, use reported proof of concept (if exists) and even write their own exploit,” security researchers Ilay Goldman and Yakir Kadkoda explained.

Sometimes the period of time between a vulnerability switching from 0-day (unknown to the maintainer) to 1-day status (known to the maintainer, has a CVE, and usually there is an available patch) is short and the risk of attackers finding the publicly available information neccessary to create and leverage an exploit during it is small. (For example, that period for Log4Shell was around 10 days.)

Other times, though, it may be monthslong, providing a large window of opportunity.

A call to action for open-source project maintainers

“Although there is no concrete evidence to suggest that attackers are actively exploiting [these flaws in the vulnerability disclosure proces] in the wild, it is reasonable to assume that threat actors may harvest information from open-source projects. They could be using this data to gain a deeper understanding of the projects and to search for potential vulnerabilities,” the researchers noted.

They have also demonstrated how it’s possible to identify such vulnerabilities on a large scale.

“Sometimes, CVEs are uploaded to the NVD before an official patch is released, happening too early in the disclosure process’s lifetime,” they noted.

“By utilizing the NVD API to fetch recently pushed CVEs and searching for GitHub references, we can then check if the commit/PR referenced by NVD has a release on GitHub that includes them.”

They’ve also released a proof-of-concept tool that can do that, though the final check of whether the commit or pull request holds helpful info is on the user.

CVE Half-Day Watcher in action (Source: Aqua Security)

Their goal, though, is not to make things easier for attackers. Instead, they want to push project maintainers to minimize or close the window of opportunity for attackers, by:

• Creating a responsible disclosure policy that outlines a secure process for vulnerability management (if they don’t have one yet)
• Leveraging GitHub’s private reporting feature to manage vulnerabilities discreetly
• Regularly scanning their code commits, issues, and pull requests for trigger words, to prevent early exposure.