vuln_playbook.md (12010B)
1 # Security Vulnerabilities Playbook 2 3 ## Reporting security bugs 4 5 Report security bugs by emailing libjxl-security@google.com. 6 7 Don't open a GitHub issue, don't discuss it public forums like Discord and don't 8 send a Pull Request if you think you have found a security bug. 9 10 ## Overview 11 12 This document outlines the guidelines followed by the project when handling 13 security bugs, their fixes, disclosure and coordination with security 14 researchers. For more context about this guide, read the [coordinated 15 vulnerability disclosure 16 guidelines](https://github.com/google/oss-vulnerability-guide/blob/main/guide.md) 17 from Google Open Source Programs Office. 18 19 The main target audience of this guide is the coordinator from the libjxl 20 Vulnerability Management Team (VMT) handling the requests, however it is useful 21 for other people to understand what to expect from this process. 22 23 Members of the VMT monitor the reports received by email and will coordinate 24 for these to be addressed. This doesn't mean that said member would fix the bug, 25 but their responsibility is to make sure it is handled properly according to 26 this guide. 27 28 ## Life of security bug 29 30 The Coordinator from VMT will make sure that the following steps are taken. 31 32 1. Acknowledge the bug report. 33 34 Our policy mandates a maximum of **3 business days** to respond to bug reports 35 in the given email, but you should respond as soon as possible and keep a fluid 36 communication with the reporter, who has spent some time looking at the issue. 37 38 2. Determine if the bug is a security bug covered by our policy. 39 40 Not all bugs are security bugs, and not all security bugs are covered by this 41 vulnerability disclosure policy. See the [What's a Security bug] section below. 42 43 3. Determine the affected versions. 44 45 Often new bugs on stable projects are found on new features or because of those 46 new features, so only the most recent versions are affected. It is important to 47 determine both what older versions are affected, so users running those older 48 versions can patch or update the software, and also what older versions are 49 *not* affected. It is possible that stable distributions ship older versions 50 that didn't contain the bug and therefore don't need to patch the code. Often 51 maintainers of package distributions need to patch older versions instead of 52 updating due to incompatibilities with newer ones and they need to understand 53 what's the vulnerable code. 54 55 Security bugs that have already been fixed in `main` or in already released code 56 but not disclosed as a vulnerability, for example if fixed as a result of a 57 refactor, should be treated like any other security bug in this policy and 58 disclosed indicating the range of older affected versions (expect for versions 59 before 0.5, see below). In such case a new release would likely not be needed if 60 one already exists, but stable distributions may be still using those version 61 and need to be aware of the issue and fix. 62 63 If no released version is affected by the bug, for example because it was only 64 introduced in the `main` branch but not yet released, then no vulnerability 65 disclosure is needed. 66 67 Note: Versions before 0.5 are not covered by the security policy. Those versions 68 have multiple security issues and should not be used anyway. 69 70 4. Communicate with the reporter 71 72 Communicate the decision to the reporter. 73 74 If the bug was not considered a security bug or not covered by this policy, 75 explain why and direct the reporter to open a public [issue in 76 GitHub](https://github.com/libjxl/libjxl/issues) or open one on their behalf. 77 You don't need to follow the rest of the guide in this case. 78 79 If the bug *is* a covered security bug then follow the rest of this guide. 80 81 Ask the reporter how they want to be credited in the disclosure: name and 82 company affiliation if any. Security researchers often value this recognition 83 and helps them dedicate their time to finding security bugs in our project. 84 85 There's no bug bounty (monetary compensation for security bugs) available for 86 libjxl. 87 88 5. Create a Security Advisory draft in GitHub 89 90 At this point it was established that the bug is a security issue that requires 91 a vulnerability disclosure. Start by creating a Security Advisory draft in the 92 [Security Advisories](https://github.com/libjxl/libjxl/security/advisories) page 93 in GitHub. 94 95 Add a short description of the bug explaining what's the issue and what's the 96 impact of the issue. Being 'hard' or 'complex' to exploit is not a reason to 97 discard the potential impact. You can update this description later, save it as 98 a draft in GitHub. 99 100 Add the reporter to the security advisory draft if they have a GitHub account, 101 and add the project members that will be working on a fix for the bug. 102 103 Establish the severity of the issue according to the impact and tag the 104 appropriate Common Weakness Enumeration (CWE) values. This helps classify the 105 security issues according to their nature. 106 107 6. Work on a fix in a private branch 108 109 Coordinators can work on the fix themselves, use a proposed fix from the 110 reporter if there is one, or work with other project members to create one. 111 112 Work on a fix for the bug in *private*. Don't publish a Pull Request with the 113 fix like you normally do, and don't upload the fix to your libjxl fork. If you 114 ask another project member to work on it, explain them that they should follow 115 this guide. 116 117 7. Request a CVE number 118 119 The Common Vulnerabilities and Exposures (CVE) is the system used to disclose 120 vulnerabilities in software. A CVE number, like CVE-2021-NNNNNN, is a unique 121 identifier for a given vulnerability. These numbers are assigned by a CVE 122 Numbering Authority (CNA) with scope on the given project that has the 123 vulnerability. For libjxl, we use Google's Generic CNA. 124 125 For VMT coordinators at Google, file a bug at 126 [go/cve-request](https://goto.google.com/cve-request) to request a CVE. See 127 go/vcp-cna for context. 128 129 When requesting the CVE include: 130 131 * A description of the problem (example: bug when parsing this field) 132 * A description of the impact of the bug (example: OOB read, remote code 133 execution, etc) 134 * The proposed CWE id(s) determined earlier. 135 * List of affected versions. 136 * Reporter of the bug and their preferred name/company to include in the 137 disclosure. 138 * Links to the issues/fixes (if already public), these can be added later, even 139 after the CVE is public. 140 * The CPE prefix of the affected project (`cpe:2.3:a:libjxl_project:libjxl`) 141 142 When in doubt, you can discuss these with the security team while requesting it. 143 144 8. File a Security bug in Chromium (if affected). 145 146 libjxl project is in charge of updating and maintaining Chromium's libjxl 147 integration code, this includes updating the libjxl library when needed. While 148 the regular CVE disclosure process will eventually create a bug to update 149 Chromium, filing one at this stage speeds up the process. 150 151 [go/crbug](https://goto.google.com/crbug), select the "Security Bug" template 152 and complete the details. This bug will be used to keep track of what versions 153 of Chromium need backporting. The new bug in Chromium will not be public 154 initially, but will be made public some time after the issue is fixed. 155 156 9. Test the fixes on the intended releases 157 158 When disclosing a vulnerability normally two ways to fix it are offered: 159 160 * A patch or set of patches that fix the issue on `main` branch, and 161 * A new release that contains the security fix for the user to update to. 162 163 New releases that fix the vulnerability should be PATCH releases, that is, a 164 previous release (like 1.2.3) plus the patches that fix the vulnerability, 165 becoming a new version (like 1.2.4). See the [release process](release.md) for 166 details. At least the latest MINOR release branch should have a PATCH release 167 with the fix, however it might make sense to also backport the fix to older 168 minor branch releases, depending on long-term support schedule for certain 169 releases. For example, if many users are still using a particular older version 170 of the library and updating to a new version requires significant changes (due 171 to a redesigned API or new unavailable dependencies) it is helpful to provide a 172 PATCH release there too. 173 174 In either case, make sure that you test the fix in all the branches that you 175 intend to release it to. 176 177 The Continuous Integration pipelines don't work on the private forks created by 178 the Security Advisory, so manual testing of the fix is needed there before 179 making it public. Don't upload it to your public fork for testing. 180 181 10. Coordinate a date for release of the vulnerability disclosure. 182 183 Agree with the reporter and security folks from the CNA on a release date. There 184 is a maximum of 90 day disclosure timeline from the day the bug was reported. 185 186 On the disclosure date publish the fixes and tag the new PATCH release with the 187 fix. You can prepare private drafts of the release for review beforehand to 188 reduce the workload. 189 190 Update Chromium to the new release version (if affected) and work with Chrome 191 engineers on the required backports. 192 193 ## What's a Security bug 194 195 A security bug is a bug that can potentially be exploited to let an attacker 196 gain unauthorized access or privileges. For example, gaining code execution in 197 libjxl decoder by decoding a malicious .jxl file is a security but hitting a 198 `JXL_ASSERT()` is not necessarily one. 199 200 The supported use cases to consider in the context of security bugs that require 201 a vulnerability disclosure are "release" builds. The disclosure is intended for 202 users of the project, to let them know that there is a security issue and that 203 they should update or patch it. 204 205 Unreleased versions are not relevant in this context. A bug introduced in the 206 `main` branch that is not yet in any release is not covered by this guide even 207 if the bug allows a remote code execution. CVEs should have a non-empty list of 208 affected released versions. 209 210 "Developer only" code is also not covered by this policy. In particular, tools 211 that are not installed by the build, or not installed when packaging `libjxl` 212 are not covered. For example, a bug in `tone_map` would not affect users since 213 is a developer-only tool. The rationale behind this is that users of the 214 released software will not have the developer code. This developer code is in 215 the same libjxl repository for convenience. 216 217 When considering the impact of a bug, "release" mode should be assumed. In 218 release mode `JXL_ASSERT()` and `JXL_CHECK()` are enabled, but `JXL_DASSERT()` 219 are not. This means that if a `JXL_DASSERT()` protects an out-of-bounds (OOB) 220 write, then the impact of a bug hitting the `JXL_DASSERT()` is at least an 221 OOB write. On the other hand, if a bug ends up hitting a `JXL_CHECK()` instead 222 of continuing, the only impact is the process abort instead of whatever else is 223 possible after the `JXL_CHECK()`. 224 225 Asserts in `libjxl` *tools* cause the tool process to abort, but don't affect 226 the caller. Either crashing or returning an error (non-zero exit code) would 227 have the same effect, so `JXL_ASSERT()` failures in the tools have no security 228 or functional impact. 229 230 Asserts in `libjxl` libraries, meant to be linked into other processes, cause 231 the caller process to abort, potentially causing a Denial of Service, however, 232 Denial of Service issues are *not* considered security bugs by this policy. 233 These are still issues and should be fixed, but they are not security issues. 234 235 Out-of-bounds (OOB) reads in process memory are considered security 236 vulnerabilities. OOB reads may allow an attacker to read other buffers from the 237 same process that it shouldn't have access to, even a small OOB read can 238 allow the attacker to read an address in the stack or in the heap, defeating 239 address space randomization techniques. In combination with other bugs these 240 can enable or simplify attacks to the process using libjxl. OOB reads don't need 241 to require a segmentation fault to be a problem, leaking process information in 242 decoded RGB pixels could be used as part of an exploit in some scenarios. 243 244 OOB writes and remote code execution (RCE) are security bugs of at least high 245 security impact.