search

github / advisory-database

Security vulnerability database inclusive of CVEs and GitHub originated security advisories from the world of open source software.
Creative Commons Attribution 4.0 International
1.7k stars 315 forks source link

Extend GitHub's CNA scope #2718

Open Marcono1234 opened 12 months ago

Marcono1234 commented 12 months ago

(Possibly this is the wrong place for this request; in that case please point me to where I should request this instead)

TLDR: Extend GitHub's CNA scope so that MITRE or other CNAs cannot file bogus CVE entries for GitHub projects anymore.

In the past there have been multiple bogus CVE IDs assigned for projects on GitHub where the maintainers were either not properly informed, or not informed at all. Some examples are:

In all those cases MITRE was the CNA who assigned the CVE ID.

These CVE entries harm everyone involved:

The CVE site describes MITRE as "CNA of Last Resort" for vulnerabilities which are "not already covered by a CNA listed on this website". Some of the affected projects (curl and Jackson) are now considering to become their own CNA just to prevent bogus CVEs filed against their projects. This is certainly not the solution to this issue, otherwise you end up with hundreds or thousands of CNAs, and being their own CNA probably also adds additional work for project maintainers.

Nowadays many popular GitHub projects have their own procedure for how vulnerabilities should be reported (described in SECURITY.md files), and are working together with other CNAs, such as HackerOne to handle vulnerability reports.

Additionally, every GitHub project can request a CVE ID themselves, see the documentation.

The CNA scope of GitHub is currently:

GitHub currently only covers CVEs requested by software maintainers using the GitHub Security Advisories feature

Maybe this should be extended so that other CNAs cannot by default file CVEs for GitHub projects, except for rare cases like arbitration or for unmaintained repositories, or when these CNAs are working together with the maintainers already, e.g. HackerOne for some repositories.

For comparison, GitLab's CNA scope is more extensive:

The GitLab application, any project hosted on GitLab.com in a public repository, and any vulnerabilities discovered by GitLab that are not in another CNA’s scope

And in the past years the only disputed CVE for a project hosted on GitLab I could find was CVE-2022-35414, and that actually seems to be reasonable report. Possibly my script to find these CVEs was not reliable enough, or maybe there are not as much projects on GitLab as on GitHub, but it could also indicate that their CNA scope did actually prevent bogus CVE requests.

I have also sent a similar request to MITRE asking them to reject CVE requests for GitHub projects in most cases and tell the requester to contact the repository maintainers instead, with the same reasoning mentioned above.

What do you think?

Maybe there are current cases though where some maintainers don't want to request a CVE ID themselves, and prefer if the reporter does this. Though possibly because the maintainers are not aware that they can use GitHub Advisories to request a CVE ID?

vin01 commented 12 months ago

If you need more examples of such CVEs, other notable projects on Github which have faced this issue in recent past include: keepassxc, scipy, h2.

I have compiled a list and some links while trying to assess how bad it really is: https://github.com/vin01/bogus-cves

aelnosu commented 3 months ago

Maybe there are current cases though where some maintainers don't want to request a CVE ID themselves and prefer if the reporter does this. Though possibly because the maintainers are not aware that they can use GitHub Advisories to request a CVE ID?

There needs to be a system in place for a developer outside the organization to file a CVE ID request as some projects are either archived, no longer maintained, or simply do not want a CVE associated with their project.

Marcono1234 commented 3 months ago

You can directly request a CVE ID from MITRE: https://cveform.mitre.org/ But note that MITRE acts as "CNA of Last Resort", so you should always try to contact the maintainers first. Maybe the disagreement with the maintainers just comes from them not being familiar with the process yet, or maybe there is some misunderstanding regarding the vulnerability (or an issue with the testing setup of the researcher). Otherwise you might just cause similar incidents with bogus or misleading CVEs as listed above, which the suggestion here tries to avoid.

Edit: Or do you mean if this proposal here was implemented, it should still be possible to get CVE IDs assigned in the cases you mentioned? But that is what I meant with "except for rare cases like arbitration or for unmaintained repositories" in the suggestion above.

or simply do not want a CVE associated with their project

Maybe you could recommend them to have a look at https://github.blog/2022-04-22-removing-the-stigma-of-a-cve/; and there are probably other good resources as well.

Tristan971 commented 3 months ago

Maybe you could recommend them to have a look at […]

No offense to the good intentioned people who wrote this at GitHub, but this is entirely unhelpful.

This is what happens in practice:

  1. A CVE is assigned on a project
  2. Many companies immediately block build/deploy flows for any software of theirs whose BOM includes it, ignoring all CVE details besides its score
  3. Operators/developers (often confused, often scared, sometimes angry) harass maintainers about it (who sometimes learn of it at all that way!)

Overwhelmingly, maintainers care little about the « CVE » label, and are just pissed when they get harassed about one that they disputed once they heard of it later (and thus it was already spread around as-is and takes days if not weeks to get the dispute flagged on it).

The only 2 reasonable levers of action for this all:

aelnosu commented 2 months ago

Sorry, I forgot to track this repo, what I mean is for other Github users to report the potential CVE to Github CNA directly, as many projects on GitHub do not have any security policy and more importantly no way to contact the maintainer

aelnosu commented 2 months ago

One example of a CVE I will not be able to report to anyone if the scope is extended is on a project like https://github.com/killsecurly/ONC/security and https://github.com/dragon731012/Innate/security

Where the repo owner does not have any social in their bio and has not enabled private Vulnerability reporting.

Marcono1234 commented 2 months ago

Where the repo owner does not have any social in their bio and has not enabled private Vulnerability reporting.

Currently the best approach is probably creating an issue in that repository, generally asking for how to report a potential security vulnerability, without publicly disclosing too much information. And maybe pointing the maintainer to GitHub private vulnerability reporting.

As reporter it would of course be great if GitHub could help, but I am not sure if GitHub really wants to become the middleman in that case and chase the maintainer for answers. Or if they should just publish the advisory if the repository has no security policy / vulnerability reporting enabled. That might then make it a bit easier for the maintainer to reject it afterwards again (since GitHub was the CNA), but might still cause inconveniences for the maintainer, especially if the advisory has been synchronized to / picked up by other vulnerability databases.

aelnosu commented 2 months ago

I did not think of this at first, but I can always check the committer's email by adding .patch to the commit. edit: Nevermind, it will just show that the commit is from @users.noreply.github.com Sidenote: the SECURITY.md in this repo does not make sense, someone should make a pr and fix it, this is not a GitHub action repo.