]>
Commit | Line | Data |
---|---|---|
c4098bc2 SP |
1 | # The GNU C Library Security Process |
2 | ||
3 | This document describes the process 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 process 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 private security bugs | |
121 | ||
122 | **IMPORTANT: All bugs reported in Bugzilla are public.** | |
123 | ||
124 | As a rule of thumb, security vulnerabilities which are exposed over the network | |
125 | or can be used for local privilege escalation (through existing applications, | |
126 | not synthetic test cases) should be reported privately. We expect that such | |
127 | critical security bugs are rare, and that most security bugs can be reported in | |
128 | Bugzilla, thus making them public immediately. If in doubt, you can file a | |
129 | private bug, as explained in the next paragraph. | |
130 | ||
131 | If you want to report a _private_ security bug that is not immediately | |
132 | public, please contact _one_ of our downstream distributions with security | |
133 | teams. The follow teams have volunteered to handle such bugs: | |
134 | ||
135 | * Debian: security@debian.org | |
136 | * Red Hat: secalert@redhat.com | |
137 | * SUSE: security@suse.de | |
138 | ||
139 | Please report the bug to _just one_ of these teams. It will be shared with | |
140 | other teams as necessary. | |
141 | ||
142 | The team you contacted will take care of details such as vulnerability rating | |
143 | and [CVE assignment](http://cve.mitre.org/about/). It is likely that the team | |
144 | will ask to file a public bug because the issue is sufficiently minor and does | |
145 | not warrant an embargo. An embargo is not a requirement for being credited | |
146 | with the discovery of a security vulnerability. | |
147 | ||
148 | ## Reporting public security bugs | |
149 | ||
150 | We expect that critical security bugs are rare, and that most security bugs can | |
151 | be reported in Bugzilla, thus making them public immediately. When reporting | |
152 | public security bugs the reporter should provide rationale for their choice of | |
153 | public disclosure. | |
154 | ||
155 | ## Triaging security bugs | |
156 | ||
157 | This section is aimed at developers, not reporters. | |
158 | ||
159 | Security-relevant bugs should be marked with `security+`, as per the [Bugzilla | |
160 | security flag | |
161 | documentation](https://sourceware.org/glibc/wiki/Bugzilla%20Procedures#security), | |
162 | following the guidelines above. If you set the `security+` flag, you should | |
163 | make sure the following information is included in the bug (usually in a bug | |
164 | comment): | |
165 | ||
166 | * The first glibc version which includes the vulnerable code. If the | |
167 | vulnerability was introduced before glibc 2.4 (released in 2006), this | |
168 | information is not necessary. | |
169 | * The commit or commits (identified by hash) that fix this vulnerability in the | |
170 | master branch, and (for historic security bugs) the first release that | |
171 | includes this fix. | |
172 | * The summary should include the CVE names (if any), in parentheses at the end. | |
173 | * If there is a single CVE name assigned to this bug, it should be set as an | |
174 | alias. | |
175 | ||
176 | The following links are helpful for finding untriaged bugs: | |
177 | ||
178 | * [Unprocessed bugs](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=notsubstring&product=glibc&query_format=advanced&v1=security) | |
179 | * [`security?` review requests](https://sourceware.org/bugzilla/buglist.cgi?f1=flagtypes.name&o1=substring&product=glibc&query_format=advanced&v1=security%3f) | |
180 | * [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) | |
181 | ||
182 | ## Fixing security bugs | |
183 | ||
184 | For changes to master, the regular [consensus-driven | |
185 | process](https://sourceware.org/glibc/wiki/Consensus) must be followed. It | |
186 | makes sense to obtain consensus in private, to ensure that the patch is likely | |
187 | in a committable state, before disclosing an emboargoed vulnerability. | |
188 | ||
189 | Security backports to release branches need to follow the | |
190 | [release process](https://sourceware.org/glibc/wiki/Release#General_policy). | |
191 | ||
192 | Contact the [website | |
193 | maintainers](https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_website) | |
194 | and have them draft a news entry for the website frontpage to direct users to | |
195 | the bug, the fix, or the mailing list discussions. | |
196 | ||
197 | ## CVE assignment | |
198 | ||
199 | Security bugs flagged with `security+` should have [CVE identifiers](http://cve.mitre.org/about/). | |
200 | ||
201 | For bugs which are public (thus all bugs in Bugzilla), CVE assignment has to | |
202 | happen through the [oss-security mailing | |
203 | list](http://oss-security.openwall.org/wiki/mailing-lists/oss-security). | |
204 | (Downstreams will eventually request CVE assignment through their public | |
205 | Bugzilla monitoring processes.) | |
206 | ||
207 | For initially private security bugs, CVEs will be assigned as needed by the | |
208 | downstream security teams. Once a public bug is filed, the name should be | |
209 | included in Bugzilla. |