Hi, Siddhesh Thanks for working on this and fine-tuning the original proposed text. It looks good to me. Minor grammatical nit below.
Thanks, David On Thu, Sep 28, 2023 at 7:59 AM Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > 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 > Some missing, pedantic commas: 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/ >
