1<!-- 2Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al. 3 4SPDX-License-Identifier: curl 5--> 6 7# curl vulnerability disclosure policy 8 9This document describes how security vulnerabilities are handled in the curl 10project. 11 12## Publishing Information 13 14All known and public curl or libcurl related vulnerabilities are listed on 15[the curl website security page](https://curl.se/docs/security.html). 16 17Security vulnerabilities **should not** be entered in the project's public bug 18tracker. 19 20## Vulnerability Handling 21 22The typical process for handling a new security vulnerability is as follows. 23 24No information should be made public about a vulnerability until it is 25formally announced at the end of this process. That means, for example, that a 26bug tracker entry must NOT be created to track the issue since that makes the 27issue public and it should not be discussed on any of the project's public 28mailing lists. Messages associated with any commits should not make any 29reference to the security nature of the commit if done prior to the public 30announcement. 31 32- The person discovering the issue, the reporter, reports the vulnerability on 33 [HackerOne](https://hackerone.com/curl). Issues filed there reach a handful 34 of selected and trusted people. 35 36- Messages that do not relate to the reporting or managing of an undisclosed 37 security vulnerability in curl or libcurl are ignored and no further action 38 is required. 39 40- A person in the security team responds to the original report to acknowledge 41 that a human has seen the report. 42 43- The security team investigates the report and either rejects it or accepts 44 it. See below for examples of problems that are not considered 45 vulnerabilities. 46 47- If the report is rejected, the team writes to the reporter to explain why. 48 49- If the report is accepted, the team writes to the reporter to let them 50 know it is accepted and that they are working on a fix. 51 52- The security team discusses the problem, works out a fix, considers the 53 impact of the problem and suggests a release schedule. This discussion 54 should involve the reporter as much as possible. 55 56- The release of the information should be "as soon as possible" and is most 57 often synchronized with an upcoming release that contains the fix. If the 58 reporter, or anyone else involved, thinks the next planned release is too 59 far away, then a separate earlier release should be considered. 60 61- Write a security advisory draft about the problem that explains what the 62 problem is, its impact, which versions it affects, solutions or workarounds, 63 when the release is out and make sure to credit all contributors properly. 64 Figure out the CWE (Common Weakness Enumeration) number for the flaw. See 65 [SECURITY-ADVISORY](https://curl.se/dev/advisory.html) for help on creating 66 the advisory. 67 68- Request a CVE Id for the issue. curl is a CNA (CVE Numbering Authority) and 69 can request its own numbers. 70 71- Update the "security advisory" with the CVE number. 72 73- The security team commits the fix in a private branch. The commit message 74 should ideally contain the CVE number. If the severity level of the issue is 75 set to Low or Medium, the fix is allowed to get merged into the master 76 repository via a normal PR - but without mentioning it being a security 77 vulnerability. 78 79- The monetary reward part of the bug-bounty is managed by the Internet Bug 80 Bounty team and the reporter is asked to request the reward from them after 81 the issue has been completely handled and published by curl. 82 83- No more than 10 days before release, inform 84 [distros@openwall](https://oss-security.openwall.org/wiki/mailing-lists/distros) 85 to prepare them about the upcoming public security vulnerability 86 announcement - attach the advisory draft for information with CVE and 87 current patch. 'distros' does not accept an embargo longer than 14 days and 88 they do not care for Windows-specific flaws. 89 90- No more than 48 hours before the release, the private branch is merged into 91 the master branch and pushed. Once pushed, the information is accessible to 92 the public and the actual release should follow suit immediately afterwards. 93 The time between the push and the release is used for final tests and 94 reviews. 95 96- The project team creates a release that includes the fix. 97 98- The project team announces the release and the vulnerability to the world in 99 the same manner we always announce releases. It gets sent to the 100 curl-announce, curl-library and curl-users mailing lists. 101 102- The security webpage on the website should get the new vulnerability 103 mentioned. 104 105## security (at curl dot se) 106 107This is a private mailing list for discussions on and about curl security 108issues. 109 110Who is on this list? There are a couple of criteria you must meet, and then we 111might ask you to join the list or you can ask to join it. It really is not a 112formal process. We basically only require that you have a long-term presence 113in the curl project and you have shown an understanding for the project and 114its way of working. You must have been around for a good while and you should 115have no plans of vanishing in the near future. 116 117We do not make the list of participants public mostly because it tends to vary 118somewhat over time and a list somewhere only risks getting outdated. 119 120## Publishing Security Advisories 121 1221. Write up the security advisory, using markdown syntax. Use the same 123 subtitles as last time to maintain consistency. 124 1252. Name the advisory file after the allocated CVE id. 126 1273. Add a line on the top of the array in `curl-www/docs/vuln.pm`. 128 1294. Put the new advisory markdown file in the `curl-www/docs/` directory. Add it 130 to the git repository. 131 1325. Run `make` in your local web checkout and verify that things look fine. 133 1346. On security advisory release day, push the changes on the curl-www 135 repository's remote master branch. 136 137## HackerOne 138 139Request the issue to be disclosed. If there are sensitive details present in 140the report and discussion, those should be redacted from the disclosure. The 141default policy is to disclose as much as possible as soon as the vulnerability 142has been published. 143 144## Bug Bounty 145 146See [BUG-BOUNTY](https://curl.se/docs/bugbounty.html) for details on the 147bug bounty program. 148 149# Severity levels 150 151The curl project's security team rates security problems using four severity 152levels depending how serious we consider the problem to be. We use **Low**, 153**Medium**, **High** and **Critical**. We refrain from using numerical scoring 154of vulnerabilities. 155 156When deciding severity level on a particular issue, we take all the factors 157into account: attack vector, attack complexity, required privileges, necessary 158build configuration, protocols involved, platform specifics and also what 159effects a possible exploit or trigger of the issue can lead do, including 160confidentiality, integrity or availability problems. 161 162## Low 163 164This is a security problem that is truly hard or unlikely to exploit or 165trigger. Due to timing, platform requirements or the fact that options or 166protocols involved are rare etc. [Past 167example](https://curl.se/docs/CVE-2022-43552.html) 168 169## Medium 170 171This is a security problem that is less hard than **Low** to exploit or 172trigger. Less strict timing, wider platforms availability or involving more 173widely used options or protocols. A problem that usually needs something else 174to also happen to become serious. [Past 175example](https://curl.se/docs/CVE-2022-32206.html) 176 177## High 178 179This issue in itself a serious problem with real world impact. Flaws that can 180easily compromise the confidentiality, integrity or availability of resources. 181Exploiting or triggering this problem is not hard. [Past 182example](https://curl.se/docs/CVE-2019-3822.html) 183 184## Critical 185 186Easily exploitable by a remote unauthenticated attacker and lead to system 187compromise (arbitrary code execution) without requiring user interaction, with 188a common configuration on a popular platform. This issue has few restrictions 189and requirements and can be exploited easily using most curl configurations. 190[Past example](https://curl.se/docs/CVE-2000-0973.html) 191 192# Not security issues 193 194This is an incomplete list of issues that are not considered vulnerabilities. 195 196## Small memory leaks 197 198We do not consider a small memory leak a security problem; even if the amount 199of allocated memory grows by a small amount every now and then. Long-living 200applications and services already need to have counter-measures and deal with 201growing memory usage, be it leaks or just increased use. A small memory or 202resource leak is then expected to *not* cause a security problem. 203 204Of course there can be a discussion if a leak is small or not. A large leak 205can be considered a security problem due to the DOS risk. If leaked memory 206contains sensitive data it might also qualify as a security problem. 207 208## Never-ending transfers 209 210We do not consider flaws that cause a transfer to never end to be a security 211problem. There are already several benign and likely reasons for transfers to 212stall and never end, so applications that cannot deal with never-ending 213transfers already need to have counter-measures established. 214 215If the problem avoids the regular counter-measures when it causes a never- 216ending transfer, it might be a security problem. 217 218## Not practically possible 219 220If the flaw or vulnerability cannot practically get executed on existing 221hardware it is not a security problem. 222 223## API misuse 224 225If a reported issue only triggers by an application using the API in a way 226that is not documented to work or even documented to not work, it is probably 227not going to be considered a security problem. We only guarantee secure and 228proper functionality when the APIs are used as expected and documented. 229 230There can be a discussion about what the documentation actually means and how 231to interpret the text, which might end up with us still agreeing that it is a 232security problem. 233 234## Local attackers already present 235 236When an issue can only be attacked or misused by an attacker present on the 237local system or network, the bar is raised. If a local user wrongfully has 238elevated rights on your system enough to attack curl, they can probably 239already do much worse harm and the problem is not really in curl. 240 241## Experiments 242 243Vulnerabilities in features which are off by default (in the build) and 244documented as experimental, are not eligible for a reward and we do not 245consider them security problems. 246 247## URL inconsistencies 248 249URL parser inconsistencies between browsers and curl are expected and are not 250considered security vulnerabilities. The WHATWG URL Specification and RFC 2513986+ (the plus meaning that it is an extended version) [are not completely 252interoperable](https://github.com/bagder/docs/blob/master/URL-interop.md). 253 254Obvious parser bugs can still be vulnerabilities of course. 255 256## Visible command line arguments 257 258The curl command blanks the contents of a number of command line arguments to 259prevent them from appearing in process listings. It does not blank all 260arguments even if some of them that are not blanked might contain sensitive 261data. We consider this functionality a best-effort and omissions are not 262security vulnerabilities. 263 264 - not all systems allow the arguments to be blanked in the first place 265 - since curl blanks the argument itself they area readable for a short moment 266 no matter what 267 - virtually every argument can contain sensitive data, depending on use 268 - blanking all arguments would make it impractical for users to differentiate 269 curl command lines in process listings 270 271## Busy-loops 272 273Busy-loops that consume 100% CPU time but eventually end (perhaps due to a set 274timeout value or otherwise) are not considered security problems. Applications 275are supposed to already handle situations when the transfer loop legitimately 276consumes 100% CPU time, so while a prolonged such busy-loop is a nasty bug, we 277do not consider it a security problem. 278 279## Saving files 280 281curl cannot protect against attacks where an attacker has write access to the 282same directory where curl is directed to save files. 283 284## Tricking a user to run a command line 285 286A creative, misleading or funny looking command line is not a security 287problem. The curl command line tool takes options and URLs on the command line 288and if an attacker can trick the user to run a specifically crafted curl 289command line, all bets are off. Such an attacker can just as well have the 290user run a much worse command that can do something fatal (like 291`sudo rm -rf /`). 292 293## Terminal output and escape sequences 294 295Content that is transferred from a server and gets displayed in a terminal by 296curl may contain escape sequences or use other tricks to fool the user. This 297is curl working as designed and is not a curl security problem. Escape 298sequences, moving cursor, changing color etc, is also frequently used for 299good. To reduce the risk of getting fooled, save files and browse them after 300download using a display method that minimizes risks. 301
