On 2023-08-10 14:28, Richard Sandiford wrote:
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.
I see what you mean, but the context-dependence of a bug is something
GCC will have to deal with, similar to how libraries have to deal with
bugs. But I agree this probably needs some more expansion. Let me try
and come up with something more detailed for that last paragraph.
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.
Missed hardening in general does not put systems at immediate risk, so
they're not considered CVE-worthy. In fact when bugs are evaluated for
security risk at a source level (e.g. when NIST does it), hardening does
not come into the picture at all. It's only at product levels that
hardening features are accounted for, e.g. where -fstack-protector would
reduce the seriousness of a stack buffer overflow and even there one
must do an analysis to see if the generated code actually mitigated the
overflow using the stack protector canary.
Thanks,
Sid
