sparc: Fix llrint and llround missing exceptions on SPARC V8
[glibc.git] / SECURITY.md
blobe0f68f1ecbf96acf1fbe3c609cbbb2c8b4d759f4
1 # The GNU C Library Security Policy
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.
12 ## What is a security bug?
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.
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.
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.
52 ### Security Exceptions
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.
59 #### Regular expression processing
61 Regular expression processing comes in two parts, compilation (through regcomp)
62 and execution (through regexec).
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.
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):
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
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.
83 #### wordexp patterns
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).
90 #### Asynchronous I/O
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.
98 #### Asynchronous cancellation
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.
105 #### Crafted binaries and ldd
107 The `ldd` tool is not expected to be used with untrusted executables.
109 #### Post-exploitation countermeasures
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.
120 ## Reporting security bugs
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.
128 ## Triaging security bugs
130 This section is aimed at developers, not reporters.
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):
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.
149 The following links are helpful for finding untriaged bugs:
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)
155 ## Fixing security bugs
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.
162 Security backports to release branches need to follow the
163 [release process](https://sourceware.org/glibc/wiki/Release#General_policy).
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.
170 ## CVE assignment
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.