Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Security / Software Development

CVE Half-Day Watcher Closes Vulnerability Disclosure Gap

A new tool empowers users to proactively identify and mitigate risks in their projects or those they rely on.
Jan 4th, 2024 8:52am by
Featued image for: CVE Half-Day Watcher Closes Vulnerability Disclosure Gap
Image from Vit Kovalcik on Shutterstock.

Security researchers have uncovered a critical gap in the public disclosure of vulnerabilities within open source projects. This gap poses a substantial risk, as it enables attackers to exploit vulnerabilities before they are officially patched and announced. Basically, attackers can leverage these vulnerabilities during the disclosure process, before an official CVE notice has been issued and a patch is made available.

By conducting a comprehensive analysis of commits, pull requests and issues on GitHub, while also extracting insights from the National Vulnerabilities Database (NVD) data set, it becomes feasible to identify vulnerabilities during their disclosure phase.

The Challenge of Early Disclosure in Open Source Projects

The open source community thrives on transparency and collaboration. However, this openness can sometimes backfire, especially when it comes to security vulnerabilities. The early disclosure of a security flaw, especially in widely used open source projects, can have far-reaching consequences. It can turn into a race against time, where developers scramble to patch the vulnerability while attackers simultaneously work to find and exploit it.

Analysis of Log4Shell (CVE-2021-44228) Disclosure Process

To shed light on this issue, let’s dive into the timeline of disclosing and patching the well-known Log4Shell vulnerability. We will emphasize the inherent disparities in the disclosure and reporting procedures.

For many practitioners, the Log4Shell vulnerability signifies a pivotal moment in their perception of the risks of vulnerabilities. Many practitioners worked tirelessly to patch this vulnerability upon its initial discovery. To recap, Alibaba discovered and reported Log4Shell to Apache on November 24, 2021. It gained wider attention through a tweet on December 9, 2021, quickly evolving into a significant concern.

We will analyze the activity within the relevant GitHub repository during this period to highlight the evolving stages of the vulnerability.

As the saying goes, a picture is worth a thousand words, so we will commence with a visual timeline chart, followed by a detailed breakdown of each stage.

Chart Breakdown:

  1. The vulnerability was reported to the Apache team on November 24, 2021.
  2. Six days later, on November 30, a maintainer opened a pull request on GitHub containing a commit that resolved the issue. At this point, the vulnerability and its details became accessible to anyone on GitHub and were essentially publicly exposed.
  3. On December 5, five days after the pull request, it was merged. However, no official patch was available at this point, the fix resided solely within the open source code.
  4. A day later, December 6, the first official patch became available on Apache’s website.

In summary: The vulnerability was exposed on public platforms like GitHub for six days (November 30 to December 6, 2021). This timeframe provided attackers with the opportunity to detect the problem, identify the vulnerable code and potentially craft an exploit before users became aware and could implement a patch.

It’s important to note that, at this stage, scanning tools couldn’t detect the issue due to the absence of a CVE number and CPE for the vulnerability.

  • On December 10, four days later, an official CVE identifier for the vulnerability was released. This marked the first time that some vulnerability scanning tools had the necessary data to detect this vulnerability.

In summary: For four days (December 6-10, 2021), the vulnerability was exposed on open source platforms. An official patch was available from Apache during this time. However, attackers could still exploit the vulnerability against users who hadn’t applied the patch, since scanning tools could only effectively identify this CVE in user environments after Decmber 10.

  • On December 13, NIST assigned a score and CPE to the CVE. This provided scanning tools with more detailed insight into the vulnerability’s impact on various software, products and versions. Additionally, it aided users in prioritizing this CVE in their vulnerability management systems.

Log4Shell is just one well-known example showcasing the existing gap. Another more recent example is Azure CLI CVE-2023-36052, which was publicly exposed in a GitHub issue for 189 days before Microsoft issued a patch. This extended exposure time provided attackers ample opportunity to exploit the vulnerability.

Until now, there had been no way to shorten this critical gap in the disclosure process.

Introducing CVE Half-Day Watcher

To tackle this concerning issue, we developed the CVE Half-Day Watcher. This tool highlights the risks associated with early CVE exposure, tracking instances of vulnerabilities to confirm whether projects are prematurely exposed. It operates by scanning the NVD for new CVEs and examining related GitHub activities such as commits, pull requests or issues associated with a new CVE. It verifies whether a patch for the reported issue was implemented after the initial indication of a vulnerability. This empowers users to proactively identify and mitigate risks in their projects or those they rely on.

The CVE Half-Day Watcher aims to shine a light on these risks, illustrating how exposed vulnerabilities can be easily discovered and potentially exploited. This situation underscores the importance of refraining from publicly disclosing security issues during their sensitive triage and disclosure phase. Creating awareness represents the initial step in mitigating these risks. By understanding vulnerabilities, users can take various actions to safeguard themselves and their projects.

For more information, please visit the tool on GitHub and read our blog.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.