Siddhesh Poyarekar <siddh...@gotplt.org> writes: > 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 > > """ > 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. > > 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.
I think this leaves open the interpretation "every wrong code bug is potentially a security bug". I suppose that's true in a trite sense, but not in a useful sense. As others said earlier in the thread, whether a wrong code bug in GCC leads to a security bug in the object code is too application-dependent to be a useful classification for GCC. I think we should explicitly say that we don't generally consider wrong code bugs to be security bugs. Leaving it implicit is bound to lead to misunderstanding. There's another case that I think should be highlighted explicitly: GCC provides various security-hardening features. I think any failure of those feature to act as documented is poentially a security bug. Failure to follow reasonable expectations (even if not documented) might sometimes be a security bug too. Thanks, Richard > > 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. > > 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.
