diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/BUG-BOUNTY.md | 89 | ||||
| -rw-r--r-- | docs/BUGS | 11 | ||||
| -rw-r--r-- | docs/Makefile.am | 1 | ||||
| -rw-r--r-- | docs/SECURITY-PROCESS.md | 51 |
4 files changed, 122 insertions, 30 deletions
diff --git a/docs/BUG-BOUNTY.md b/docs/BUG-BOUNTY.md new file mode 100644 index 000000000..5927762d2 --- /dev/null +++ b/docs/BUG-BOUNTY.md @@ -0,0 +1,89 @@ +# The curl bug bounty + +The curl project runs a bug bounty program in association with +[HackerOne](https://www.hackerone.com/). + +# How does it work? + +Start out by posting your suspected security vulnerability directly to [curl's +hackerone security bug tracker](https://www.hackerone.com/curl). + +After you have reported a security issue, it has been deemed credible and a +patch and advisory has been made public you can be eligible for a bounty from +this program. + +See all details at [https://hackerone.com/curl](https://hackerone.com/curl) + +This bounty is relying on funds from sponsors. If you use curl professionally, +consider help funding this! + +# How much money is the bounty at + +The curl projects offer monetary compensation for reported and published +security vulnerabilities. The amount of money that is rewarded depends on how +serious the flaw is determined to be. + +We offer reward money *up to* a certain amount per severity. The curl security +team determines the severity of each reported flaw on a case by case basis and +the exact amount rewarded to the reporter is then decided. + +At the start of the program, the award amounts are: + + Critical: 2,000 USD + High: 1,500 USD + Medium: 1,000 USD + Low: 500 USD + +# Who's eligible for a reward + +Everyone and anyone who reports a security problem in a released curl version +that hasn't already been reported can ask for a bounty. + +Vulnerabilities in features which are off by default and documented as +experimental, are not eligible for a reward. + +The vulnerability has to be fixed and publicly announced (by the curl project) +before a bug bounty will be considered. + +Bounties need to be requested within twelve months from the publication of the +vulnerability. + +The vulnerabilities must not have been made public before February 1st, 2019. +We do not retroactively pay for old, already known and published security +problems. + +# Product vulnerabilities only + +This bug bounty only concerns the curl and libcurl products and thus their +respective source codes - when running on existing hardware. It does not +include documentation, web sites or other infrastructure. + +The curl security team will be the sole arbiter if a reported flaw can be +subject to a bounty or not. + +# How are vulnerabilities graded + +The grading of each reported vulnerability that makes a reward claim will be +performed by the curl security team. The grading will be based on the CVSS +(Common Vulnerability Scoring System) 3.0. + +# How are reward amounts determined + +The curl security team first gives the vulnerability a score, as mentioned +above, and based on that level we set an amount depending on the specifics of +the individual case. Other sponsors of the program might also get involved and +can raise the amounts depending on the particular issue. + +# What happens if the bounty fund is drained + +The bounty fund depends on sponsors. If we pay out more bounties than we add, +the fund will eventually drain. If that end up happening, we will simply not +be able to pay out as high bounties as we would like and hope that we can +convince new sponsors to help us top up the fund again. + +# Regarding taxes etc on the bounties + +In the event that the individual receiving a curl bug bounty needs to pay +taxes on the reward money, that's something for the receiver to work out and +handle together with hackerone. The curl project or its security team never +actually receive any of this money, hold the money or pay out the money. @@ -61,9 +61,14 @@ BUGS using our security development process. Security related bugs or bugs that are suspected to have a security impact, - should be reported by email to curl-security@haxx.se so that they first can - be dealt with away from the public to minimize the harm and impact it will - have on existing users out there who might be using the vulnerable versions. + should be reported on the curl security tracker at HackerOne: + + https://hackerone.com/curl + + This ensures that the report reaches the curl security team so that they + first can be deal with the report away from the public to minimize the harm + and impact it will have on existing users out there who might be using the + vulnerable versions. The curl project's process for handling security related issues is documented here: diff --git a/docs/Makefile.am b/docs/Makefile.am index 8eeabd478..e34b80488 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -44,6 +44,7 @@ EXTRA_DIST = \ $(noinst_man_MANS) \ ALTSVC.md \ BINDINGS.md \ + BUG-BOUNTY.md \ BUGS \ CHECKSRC.md \ CIPHERS.md \ diff --git a/docs/SECURITY-PROCESS.md b/docs/SECURITY-PROCESS.md index 6cae5036b..3b797b923 100644 --- a/docs/SECURITY-PROCESS.md +++ b/docs/SECURITY-PROCESS.md @@ -10,9 +10,8 @@ Publishing Information All known and public curl or libcurl related vulnerabilities are listed on [the curl web site security page](https://curl.haxx.se/docs/security.html). -Security vulnerabilities should not be entered in the project's public bug -tracker unless the necessary configuration is in place to limit access to the -issue to only the reporter and the project's security team. +Security vulnerabilities **should not** be entered in the project's public bug +tracker. Vulnerability Handling ---------------------- @@ -23,20 +22,20 @@ No information should be made public about a vulnerability until it is formally announced at the end of this process. That means, for example that a bug tracker entry must NOT be created to track the issue since that will make the issue public and it should not be discussed on any of the project's public -mailing lists. Also messages associated with any commits should not make -any reference to the security nature of the commit if done prior to the public +mailing lists. Also messages associated with any commits should not make any +reference to the security nature of the commit if done prior to the public announcement. -- The person discovering the issue, the reporter, reports the vulnerability - privately to `curl-security@haxx.se`. That's an email alias that reaches a - handful of selected and trusted people. +- The person discovering the issue, the reporter, reports the vulnerability on + https://hackerone.com/curl. Issues filed there reach a handful of selected + and trusted people. - Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in curl or libcurl are ignored and no further action is required. -- A person in the security team sends an e-mail to the original reporter to - acknowledge the report. +- A person in the security team responds to the original report to acknowledge + that a human has seen the report. - The security team investigates the report and either rejects it or accepts it. @@ -51,9 +50,9 @@ announcement. should involve the reporter as much as possible. - The release of the information should be "as soon as possible" and is most - often synced with an upcoming release that contains the fix. If the - reporter, or anyone else, thinks the next planned release is too far away - then a separate earlier release for security reasons should be considered. + often synchronized with an upcoming release that contains the fix. If the + reporter, or anyone else involved, thinks the next planned release is too + far away, then a separate earlier release should be considered. - Write a security advisory draft about the problem that explains what the problem is, its impact, which versions it affects, solutions or workarounds, @@ -61,12 +60,14 @@ announcement. Figure out the CWE (Common Weakness Enumeration) number for the flaw. - Request a CVE number from + [Hackerone](https://docs.hackerone.com/programs/cve-requests.html) + +- Consider informing [distros@openwall](https://oss-security.openwall.org/wiki/mailing-lists/distros) - when also informing and preparing them for the upcoming public security - vulnerability announcement - attach the advisory draft for information. Note - that 'distros' won't accept an embargo longer than 14 days and they do not - care for Windows-specific flaws. For windows-specific flaws, request CVE - directly from MITRE. + to prepare them about the upcoming public security vulnerability + announcement - attach the advisory draft for information. Note that + 'distros' won't accept an embargo longer than 14 days and they do not care + for Windows-specific flaws. - Update the "security advisory" with the CVE number. @@ -93,6 +94,9 @@ announcement. curl-security (at haxx dot se) ------------------------------ +This is a private mailing list for discussions on and about curl security +issues. + Who is on this list? There are a couple of criteria you must meet, and then we might ask you to join the list or you can ask to join it. It really isn't very formal. We basically only require that you have a long-term presence in the @@ -124,12 +128,5 @@ Publishing Security Advisories Hackerone Internet Bug Bounty ----------------------------- -The curl project does not run any bounty program on its own, but there are -outside organizations that do. First report your issue the normal way and -proceed as described in this document. - -Then, if the issue is [critical](https://hackerone.com/ibb-data), you are -eligible to apply for a bounty from Hackerone for your find. - -Once your reported vulnerability has been publicly disclosed by the curl -project, you can submit a [report to them](https://hackerone.com/ibb-data).
\ No newline at end of file +See [BUG-BOUNTY](BUG-BOUNTY.md) for specific details on the bug bounty +program. |