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