On 2023-09-28 12:55, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar <siddh...@gotplt.org>
---
Sorry I forgot to summarize changes since the previous version:
- Reworded the introduction so that it doesn't sound like we know *all*
scenarios and also encourage reporters to reach out.
- Fixed up support and diagnostic libraries sections based on Jakub's
feedback.
SECURITY.txt | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 205 insertions(+)
create mode 100644 SECURITY.txt
diff --git a/SECURITY.txt b/SECURITY.txt
new file mode 100644
index 00000000000..14cb31570d3
--- /dev/null
+++ b/SECURITY.txt
@@ -0,0 +1,205 @@
+What is a GCC security bug?
+===========================
+
+ A security bug is one that threatens the security of a system or
+ network, or might compromise the security 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 security 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 sandboxed environment to ensure
+ that it does not compromise the development 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 sanitizing inputs and it is recommended that both the
+ compilation *and* execution context of the code are appropriately
+ sandboxed to contain the effects of any bugs in libgccjit, the
+ application code using it, or its generated code to the sandboxed
+ 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 bundled into GCC to build it will be
+ treated the same as the compiler drivers and programs as far as
+ security 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 security 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, specifically in the following cases:
+
+ - 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 security 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 security
+ 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 security 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 security vulnerabilities in these runtime libraries arise when
+ an application uses functionality in a specific way. As a result,
+ not all bugs qualify as security relevant. The following guidelines
+ can help with the decision:
+
+ - Buffer overflows and integer overflows should be treated as
+ security 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 security bugs.
+ - Information disclosure can be security bugs, especially if
+ exposure through applications can be determined.
+ - Memory leaks and races are security bugs if they cause service
+ breakage.
+ - Stack overflow through unbounded alloca calls or variable-length
+ arrays are security 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
+ security 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 security 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 security
+ 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 security
+ issues.
+
+Security features implemented in GCC
+------------------------------------
+
+ GCC implements a number of security features that reduce the impact
+ of security issues in applications, such as -fstack-protector,
+ -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure in
+ these features functioning perfectly in all situations is not an
+ exploitable 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 security issue
+ in GCC.
+
+Reporting private security bugs
+===============================
+
+ *All bugs reported in the GCC Bugzilla are public.*
+
+ In order to report a private security bug that is not immediately
+ public, please contact one of the downstream distributions with
+ security teams. The following teams have volunteered to handle
+ such bugs:
+
+ Debian: secur...@debian.org
+ Red Hat: secal...@redhat.com
+ SUSE: secur...@suse.de
+ AdaCore: product-secur...@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 security
+ vulnerability.
+
+Reporting public security bugs
+==============================
+
+ It is expected that critical security bugs will be rare, and that most
+ security bugs can be reported in GCC, thus making
+ them public immediately. The system can be found here:
+
+ https://gcc.gnu.org/bugzilla/
