Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-08-10 14:28, Richard Sandiford wrote:
> Siddhesh Poyarekar <siddhesh@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