418sec / huntr

Public Roadmap | huntr.dev
https://huntr.dev
263 stars 90 forks source link

Maintainers can delay going public #2143

Closed jaapmarcus closed 1 year ago

jaapmarcus commented 2 years ago

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:

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 commented 2 years ago

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

jaapmarcus commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

jaapmarcus commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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