i386: fix ix86_hardreg_mov_ok with lra_in_progress
[official-gcc.git] / SECURITY.txt
blob126603d4c228742227a31a5d3a55e179c4944eef
1 What is a GCC security bug?
2 ===========================
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.
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.
14 Compiler drivers, programs, libgccjit and support libraries
15 -----------------------------------------------------------
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.
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.
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.
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.
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.
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:
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.
73 Language runtime libraries
74 --------------------------
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:
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++
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.
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:
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.
135 Diagnostic libraries
136 --------------------
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.
143 GCC plugins
144 -----------
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.
152 Security features implemented in GCC
153 ------------------------------------
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 a
159     vulnerability in itself since it does not affect the correctness of
160     programs.  Further, they're dependent on heuristics and may not
161     always have full coverage for protection.
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.
173 Reporting private security bugs
174 ===============================
176     *All bugs reported in the GCC Bugzilla are public.*
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:
183       Debian:  security@debian.org
184       Red Hat: secalert@redhat.com
185       SUSE:    security@suse.de
186       AdaCore: product-security@adacore.com
188     Please report the bug to just one of these teams.  It will be shared
189     with other teams as necessary.
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.
198 Reporting public security bugs
199 ==============================
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:
205       https://gcc.gnu.org/bugzilla/