]> git.ipfire.org Git - thirdparty/gcc.git/blob - SECURITY.txt
ada: Excess elements created for indexed aggregates with iterator_specifications
[thirdparty/gcc.git] / SECURITY.txt
1 What is a GCC security bug?
2 ===========================
3
4 A security bug is one that threatens the security of a system or
5 network, or might compromise the security of data stored on it.
6 In the context of GCC, there are multiple ways in which this might
7 happen and some common scenarios are detailed below.
8
9 If you're reporting a security issue and feel like it does not fit
10 into any of the descriptions below, you're encouraged to reach out
11 through the GCC bugzilla or, if needed, privately, by following the
12 instructions in the last two sections of this document.
13
14 Compiler drivers, programs, libgccjit and support libraries
15 -----------------------------------------------------------
16
17 The compiler driver processes source code, invokes other programs
18 such as the assembler and linker and generates the output result,
19 which may be assembly code or machine code. Compiling untrusted
20 sources can result in arbitrary code execution and unconstrained
21 resource consumption in the compiler. As a result, compilation of
22 such code should be done inside a sandboxed environment to ensure
23 that it does not compromise the host environment.
24
25 The libgccjit library can, despite the name, be used both for
26 ahead-of-time compilation and for just-in-compilation. In both
27 cases, it can be used to translate input representations (such as
28 source code) in the application context; in the latter case, the
29 generated code is also run in the application context.
30
31 Limitations that apply to the compiler driver apply here too in
32 terms of trusting inputs and it is recommended that both the
33 compilation *and* execution context of the code are appropriately
34 sandboxed to contain the effects of any bugs in libgccjit, the
35 application code using it, or its generated code to the sandboxed
36 environment.
37
38 Libraries such as libiberty, libcc1 and libcpp are not distributed
39 for runtime support and have similar challenges to compiler drivers.
40 While they are expected to be robust against arbitrary input, they
41 should only be used with trusted inputs when linked into the
42 compiler.
43
44 Libraries such as zlib that are bundled with GCC to build it will be
45 treated the same as the compiler drivers and programs as far as
46 security coverage is concerned. However, if you find an issue in
47 these libraries independent of their use in GCC, you should reach
48 out to their upstream projects to report them.
49
50 As a result, the only case for a potential security issue in the
51 compiler is when it generates vulnerable application code for
52 trusted input source code that is conforming to the relevant
53 programming standard or extensions documented as supported by GCC
54 and the algorithm expressed in the source code does not have the
55 vulnerability. The output application code could be considered
56 vulnerable if it produces an actual vulnerability in the target
57 application, for example:
58
59 - The application dereferences an invalid memory location despite
60 the application sources being valid.
61 - The application reads from or writes to a valid but incorrect
62 memory location, resulting in an information integrity issue or an
63 information leak.
64 - The application ends up running in an infinite loop or with
65 severe degradation in performance despite the input sources having
66 no such issue, resulting in a Denial of Service. Note that
67 correct but non-performant code is not a security issue candidate,
68 this only applies to incorrect code that may result in performance
69 degradation severe enough to amount to a denial of service.
70 - The application crashes due to the generated incorrect code,
71 resulting in a Denial of Service.
72
73 Language runtime libraries
74 --------------------------
75
76 GCC also builds and distributes libraries that are intended to be
77 used widely to implement runtime support for various programming
78 languages. These include the following:
79
80 * libada
81 * libatomic
82 * libbacktrace
83 * libcc1
84 * libcody
85 * libcpp
86 * libdecnumber
87 * libffi
88 * libgcc
89 * libgfortran
90 * libgm2
91 * libgo
92 * libgomp
93 * libitm
94 * libobjc
95 * libphobos
96 * libquadmath
97 * libssp
98 * libstdc++
99
100 These libraries are intended to be used in arbitrary contexts and, as
101 a result, bugs in these libraries may be evaluated for security
102 impact. However, some of these libraries, e.g. libgo, libphobos,
103 etc. are not maintained in the GCC project, due to which the GCC
104 project may not be the correct point of contact for them. You are
105 encouraged to look at README files within those library directories
106 to locate the canonical security contact point for those projects
107 and include them in the report. Once the issue is fixed in the
108 upstream project, the fix will be synced into GCC in a future
109 release.
110
111 Most security vulnerabilities in these runtime libraries arise when
112 an application uses functionality in a specific way. As a result,
113 not all bugs qualify as security relevant. The following guidelines
114 can help with the decision:
115
116 - Buffer overflows and integer overflows should be treated as
117 security issues if it is conceivable that the data triggering them
118 can come from an untrusted source.
119 - Bugs that cause memory corruption which is likely exploitable
120 should be treated as security bugs.
121 - Information disclosure can be security bugs, especially if
122 exposure through applications can be determined.
123 - Memory leaks and races are security bugs if they cause service
124 breakage.
125 - Stack overflow through unbounded alloca calls or variable-length
126 arrays are security bugs if it is conceivable that the data
127 triggering the overflow could come from an untrusted source.
128 - Stack overflow through deep recursion and other crashes are
129 security bugs if they cause service breakage.
130 - Bugs that cripple the whole system (so that it doesn't even boot
131 or does not run most applications) are not security bugs because
132 they will not be exploitable in practice, due to general system
133 instability.
134
135 Diagnostic libraries
136 --------------------
137
138 Libraries like libvtv and the sanitizers are intended to be used in
139 diagnostic cases and not intended for use in sensitive environments.
140 As a result, bugs in these libraries will not be considered security
141 sensitive.
142
143 GCC plugins
144 -----------
145
146 It should be noted that GCC may execute arbitrary code loaded by a
147 user through the GCC plugin mechanism or through system preloading
148 mechanism. Such custom code should be vetted by the user for safety,
149 as bugs exposed through such code will not be considered security
150 issues.
151
152 Security features implemented in GCC
153 ------------------------------------
154
155 GCC implements a number of security features that reduce the impact
156 of security issues in applications, such as -fstack-protector,
157 -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure of
158 these features to function perfectly in all situations is not an
159 exploitable vulnerability in itself since it does not affect the
160 correctness of programs. Further, they're dependent on heuristics
161 and may not always have full coverage for protection.
162
163 Similarly, GCC may transform code in a way that the correctness of
164 the expressed algorithm is preserved, but supplementary properties
165 that are not specifically expressible in a high-level language
166 are not preserved. Examples of such supplementary properties
167 include absence of sensitive data in the program's address space
168 after an attempt to wipe it, or data-independent timing of code.
169 When the source code attempts to express such properties, failure
170 to preserve them in resulting machine code is not a security issue
171 in GCC.
172
173 Reporting private security bugs
174 ===============================
175
176 *All bugs reported in the GCC Bugzilla are public.*
177
178 In order to report a private security bug that is not immediately
179 public, please contact one of the downstream distributions with
180 security teams. The following teams have volunteered to handle
181 such bugs:
182
183 Debian: security@debian.org
184 Red Hat: secalert@redhat.com
185 SUSE: security@suse.de
186 AdaCore: product-security@adacore.com
187
188 Please report the bug to just one of these teams. It will be shared
189 with other teams as necessary.
190
191 The team contacted will take care of details such as vulnerability
192 rating and CVE assignment (http://cve.mitre.org/about/). It is likely
193 that the team will ask to file a public bug because the issue is
194 sufficiently minor and does not warrant an embargo. An embargo is not
195 a requirement for being credited with the discovery of a security
196 vulnerability.
197
198 Reporting public security bugs
199 ==============================
200
201 It is expected that critical security bugs will be rare, and that most
202 security bugs can be reported in GCC, thus making
203 them public immediately. The system can be found here:
204
205 https://gcc.gnu.org/bugzilla/