> Am 10.08.2023 um 20:28 schrieb Richard Sandiford <richard.sandif...@arm.com>:
>
> 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.
In some sense the security bug is never in GCC itself but the consumer which is
what you need to be able to exploit
Richard
> 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.
