On 2023-08-09 14:17, David Edelsohn wrote:
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar <siddh...@gotplt.org
<mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
>> Do you have a suggestion for the language to address libgcc,
>> libstdc++, etc. and libiberty, libbacktrace, etc.?
>
> I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including the
runtime libraries. Over time we may find that specific parts of
runtime
libraries simply cannot be used safely in some contexts and flag that.
Sid
Hi, Sid
Thanks for iterating on this.
"""
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 they're detailed below.
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. It is necessary that
all source code inputs to the compiler are trusted, since it is
impossible for the driver to validate input source code beyond
conformance to a programming language standard.
The GCC JIT implementation, libgccjit, is intended to be plugged
into applications to translate input source code in the
application
context. Limitations that apply to the compiler
driver, apply here too in terms of sanitizing inputs, so it is
recommended that inputs are either sanitized by an external
program
to allow only trusted, safe execution in the context of the
application or the JIT execution context is appropriately
sandboxed
to contain the effects of any bugs in the JIT or its generated
code
to the sandboxed environment.
Support libraries such as libiberty, libcc1 libvtv and libcpp have
been developed separately to share code with other tools such as
binutils and gdb. These libraries again have similar
challenges to
compiler drivers. While they are expected to be robust against
arbitrary input, they should only be used with trusted inputs.
Libraries such as zlib and libffi 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.
Should we direct people to the upstream projects for their security
policies?
We bundle zlib and libffi so regardless of whether it's a security issue
in those libraries (because security impact of memory safety bugs in
general use libraries will be context dependent and hence get assigned
CVEs more often than not), the context in gcc is well defined as a local
unprivileged executable and hence not security-relevant.
That said, we could add something like:
However if you find a 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 all
these cases is when it ends up generating vulnerable output for
valid input source code.
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
* libgcc
* libgfortran
* libgm2
* libgo
* libgomp
* libiberty
* 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.
As Richard mentioned, should GCC make a specific statement about the
security policy / response for issues that are discovered and fixed in
the upstream projects from which the GCC libraries are imported?
Ack, how about:
You are encouraged to reach out to us or look at the README files
within those library directories to locate the canonical security
contact point for those projects and include them in the security
report. Once the security issue is addressed upstream, the GCC
project may sync code from upstream to resolve the issue in GCC.
Diagnostic libraries
--------------------
The sanitizer library bundled in GCC is intended to be used in
diagnostic cases and not intended for use in sensitive
environments.
As a result, bugs in the sanitizer 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.
Thanks, David
