SECURITY.md

   1 # The GNU C Library Security Policy
   2
   3 This document describes the policy followed by the GNU C Library maintainers
   4 to handle bugs that may have a security impact.  This includes determining if a
   5 bug has a security impact, reporting such bugs to the community and handling
   6 such bugs all the way to resolution.  This policy may evolve over time, so if
   7 you're reading this from a release tarball, be sure to check the latest copy of
   8 the [SECURITY.md in the
   9 repository](https://sourceware.org/git/?p=glibc.git;a=blob;f=SECURITY.md),
  10 especially for instructions on reporting issues privately.
  11
  12 ## What is a security bug?
  13
  14 Most security vulnerabilities in the GNU C Library materialize only after an
  15 application uses functionality in a specific way.  Therefore, it is sometimes
  16 difficult to determine if a defect in the GNU C Library constitutes a
  17 vulnerability as such.  The follow guidelines can help with a decision.
  18
  19 * Buffer overflows should be treated as security bugs if it is conceivable that
  20   the data triggering them can come from an untrusted source.
  21 * Other bugs that cause memory corruption which is likely exploitable should be
  22   treated as security bugs.
  23 * Information disclosure can be security bugs, especially if exposure through
  24   applications can be determined.
  25 * Memory leaks and races are security bugs if they cause service breakage.
  26 * Stack overflow through unbounded alloca calls or variable-length arrays are
  27   security bugs if it is conceivable that the data triggering the overflow
  28   could come from an untrusted source.
  29 * Stack overflow through deep recursion and other crashes are security bugs if
  30   they cause service breakage.
  31 * Bugs that cripple the whole system (so that it doesn't even boot or does not
  32   run most applications) are not security bugs because they will not be
  33   exploitable in practice, due to general system instability.
  34 * Bugs that crash `nscd` are generally security bugs, except if they can only
  35   be triggered by a trusted data source (DNS is not trusted, but NIS and LDAP
  36   probably are).
  37 * The [Security Exceptions](#SecurityExceptions) section below describes
  38   subsystems for which determining the security status of bugs is especially
  39   complicated.
  40 * For consistency, if the bug has received a CVE name attributing it to the GNU
  41   C library, it should be flagged `security+`.
  42 * Duplicates of security bugs (flagged with `security+`) should be flagged
  43   `security-`, to avoid cluttering the reporting.
  44
  45 In this context, _service breakage_ means client-side privilege escalation
  46 (code execution) or server-side denial of service or privilege escalation
  47 through actual, concrete, non-synthetic applications. Or put differently, if
  48 the GNU C Library causes a security bug in an application (and the application
  49 uses the library in a standard-conforming manner or according to the manual),
  50 the GNU C Library bug should be treated as security-relevant.
  51
  52 ### Security Exceptions
  53
  54 It may be especially complicated to determine the security status of bugs in
  55 some subsystems in the GNU C Library.  This subsection describes such
  56 subsystems and the special considerations applicable during security bug
  57 classification in them.
  58
  59 #### Regular expression processing
  60
  61 Regular expression processing comes in two parts, compilation (through regcomp)
  62 and execution (through regexec).
  63
  64 Implementing regular expressions efficiently, in a standard-conforming way, and
  65 without denial-of-service vulnerabilities is very difficult and impossible for
  66 Basic Regular Expressions. Most implementation strategies have issues dealing
  67 with certain classes of patterns.
  68
  69 Consequently, certain issues which can be triggered only with crafted patterns
  70 (either during compilation or execution) are treated as regular bugs and not
  71 security issues.  Examples of such issues would include (but is not limited
  72 to):
  73
  74  * Running out of memory through valid use of malloc
  75  * Quadratic or exponential behaviour resulting in slow execution time
  76  * Stack overflows due to recursion when processing patterns
  77
  78 Crashes, infinite loops (and not merely exponential behavior), buffer overflows
  79 and overreads, memory leaks and other bugs resulting from the regex
  80 implementation relying on undefined behavior should be treated as security
  81 vulnerabilities.
  82
  83 #### wordexp patterns
  84
  85 `wordexp` inherently has exponential memory consumption in terms of the input
  86 size.  This means that denial of service flaws from crafted patterns are not
  87 security issues (even if they lead to other issues, such as NULL pointer
  88 dereferences).
  89
  90 #### Asynchronous I/O
  91
  92 The GNU C Library tries to implement asynchronous I/O without kernel support,
  93 which means that several operations are not fully standard conforming.  Several
  94 known races can cause crashes and resource leaks.  Such bugs are only treated
  95 as security bugs if applications (as opposed to synthetic test cases) have
  96 security exposures due to these bugs.
  97
  98 #### Asynchronous cancellation
  99
 100 The implementation of asynchronous cancellation is not fully
 101 standard-conforming and has races and leaks.  Again, such bugs are only treated
 102 as security bugs if applications (as opposed to synthetic test cases) have
 103 security exposures due to these bugs.
 104
 105 #### Crafted binaries and ldd
 106
 107 The `ldd` tool is not expected to be used with untrusted executables.
 108
 109 #### Post-exploitation countermeasures
 110
 111 Certain features have been added to the library only to make exploitation of
 112 security bugs (mainly for code execution) more difficult.  Examples includes
 113 the stack smashing protector, function pointer obfuscation, vtable validation
 114 for stdio stream handles, and various heap consistency checks.  Failure of such
 115 countermeasures to stop exploitation of a different vulnerability is not a
 116 security vulnerability in itself.  By their nature, these countermeasures are
 117 based on heuristics and will never offer complete protection, so the original
 118 vulnerability needs to be fixed anyway.
 119
 120 ## Reporting security bugs
 121
 122 The process to report security bugs is documented on the glibc [security
 123 page](https://sourceware.org/glibc/security.html).  In general, most security
 124 bugs may be reported publicly in the [glibc
 125 bugzilla](https://sourceware.org/glibc/bugs.html), but if in doubt, please feel
 126 free to report security issues privately first.
 127
 128 ## Triaging security bugs
 129
 130 This section is aimed at developers, not reporters.
 131
 132 Security-relevant bugs should be marked with `security+`, as per the [Bugzilla
 133 security flag
 134 documentation](https://sourceware.org/glibc/wiki/Bugzilla%20Procedures#security),
 135 following the guidelines above.  If you set the `security+` flag, you should
 136 make sure the following information is included in the bug (usually in a bug
 137 comment):
 138
 139 * The first glibc version which includes the vulnerable code.  If the
 140   vulnerability was introduced before glibc 2.4 (released in 2006), this
 141   information is not necessary.
 142 * The commit or commits (identified by hash) that fix this vulnerability in the
 143   master branch, and (for historic security bugs) the first release that
 144   includes this fix.
 145 * The summary should include the CVE names (if any), in parentheses at the end.
 146 * If there is a single CVE name assigned to this bug, it should be set as an
 147   alias.
 148
 149 The following links are helpful for finding untriaged bugs:
 150
 151 * [Unprocessed bugs](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=notsubstring&product=glibc&query_format=advanced&v1=security)
 152 * [`security?` review requests](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=substring&product=glibc&query_format=advanced&v1=security%3f)
 153 * [Open `security+` bugs](https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=VERIFIED&f1=flagtypes.name&o1=substring&product=glibc&query_format=advanced&v1=security%2B)
 154
 155 ## Fixing security bugs
 156
 157 For changes to master, the regular [consensus-driven
 158 process](https://sourceware.org/glibc/wiki/Consensus) must be followed.  It
 159 makes sense to obtain consensus in private, to ensure that the patch is likely
 160 in a committable state, before disclosing an emboargoed vulnerability.
 161
 162 Security backports to release branches need to follow the
 163 [release process](https://sourceware.org/glibc/wiki/Release#General_policy).
 164
 165 Contact the [website
 166 maintainers](https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_website)
 167 and have them draft a news entry for the website frontpage to direct users to
 168 the bug, the fix, or the mailing list discussions.
 169
 170 ## CVE assignment
 171
 172 Security bugs flagged with `security+` should have [CVE
 173 identifiers](http://cve.mitre.org/about/). Please reach out to the glibc
 174 security team using the documented [security
 175 process](https://sourceware.org/glibc/security.html) and they work on getting a
 176 CVE number.