Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintainers can delay going public #2143

Closed
jaapmarcus opened this issue Sep 30, 2021 · 8 comments
Closed

Maintainers can delay going public #2143

jaapmarcus opened this issue Sep 30, 2021 · 8 comments
Labels

Comments

@jaapmarcus
Copy link

After a patch has been developed + entered in the system it would be nice to allow for a small delay for example 1 week before it get published:

Currently "Researcher" reports Vulnerability
Maintainer validates Vulnerability
Fixed will be developed and "Huntr" marks the vulnerability as fixed and publish them on the system and possible a CVE will be generated.

Incase with low impact issues for example allowing to be included It might be not an issue but for larger bugs it might be a major security issue.

For example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10966 If this would be published with 100 of servers still vulnreble and with out the possibility to give the maintainers time to publish their package and notify their users with other methods before publishing and CVE tweeting about it on the internet...

Correct method should be:

  • Currently "Researcher" reports Vulnerability
  • Maintainer validates Vulnerability
  • Fixed to be submitted
  • Reseacher validates fixed to be solved
  • Release will be published and deployed to package distribution system.
  • Vulnerability will be published

For example:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27231
It was reported in February, patched in 2 weeks later and shipped 4 month later.. As we didn't see the risks high enough and it would only a specific group of users...

@Haxatron
Copy link

I agree with this, this could also allow the possibility of retesting efforts.

@jaapmarcus
Copy link
Author

I just submitted an RCE + root escalation for a repository to Huntr.dev but decided to report it for an active fork(s) because after the fork set the vulnerability as patched it is directly published. This causes

As I am was able to execute the hack on their demo server without any issue even if they patch the vulnerability on their Github packages are not rebuild and users will not update to their last version

@jaapmarcus
Copy link
Author

For example:

https://huntr.dev/bounties/8c7001ce-acf3-401b-b1ad-4bc0813195d9/

As of day 14 October has been patched how ever a release hasn't been published users that uses are still vulnerable even with a POC online on how to abuse them.

https://github.com/ampache/ampache hasn't been released yet (05:31 GMT)

@JamieSlome
Copy link
Contributor

Thanks all for the comments.

We are currently addressing the automation and publishing of CVE controls, and giving more of this capability over to the maintainer/researcher.

Once we have delivered this, we may also allow for customization on the date of publishing. We will keep you up-to-date with any advancements in this.

@psmoros psmoros changed the title [Feature] Delay publishing Vulnerability Maintainers can delay going public Nov 10, 2021
@psmoros psmoros added the +2 label Nov 10, 2021
@psmoros psmoros added +3 and removed +2 labels Nov 12, 2021
@psmoros
Copy link
Member

psmoros commented Nov 12, 2021

Maybe we could delay publications by a set amount of time by default but let the maintainer increase or decrease it?

@jaapmarcus
Copy link
Author

A default delay of 1 / 2 days make sense. It allows users to "silently" publish the packages + notify users via their own channels instead via Twitter...

@matmair
Copy link

matmair commented Jun 27, 2022

Strong agreement from me on this @JamieSlome a publishing delay is a must. We are implementing this as a process in the project right now. It is a normal part of the disclosure process to have a long enough period before publishing.

In general I am missing some core principles of the responsible disclosure concept as it is practiced in Europe in the chaos computer club scene: https://youtu.be/Im45cSdmlQs

@psmoros
Copy link
Member

psmoros commented Nov 1, 2022

Thank you all for your input on this! Fixing and publication are now separate states :)

@psmoros psmoros closed this as completed Nov 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants