Re: [RFC] GCC Security policy

[Paul Koning <paulkoning@comcast.net>]

> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
>>>>       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.
> 
> How's this:
> 
> As a result, the only case for a potential security issue in the compiler is when it generates vulnerable application code for valid, trusted input source code.  The output application code could be considered vulnerable if it produces an actual vulnerability in the target application, specifically in the following cases:

You might make it explicit that we're talking about wrong code errors here -- in other words, the source code is correct (conforms to the standard) and the algorithm expressed in the source code does not have a vulnerability, but the generated code has semantics that differ from those of the source code such that it does have a vulnerability.

> - The application dereferences an invalid memory location despite the application sources being valid.
> 
> - The application reads from or writes to a valid but incorrect memory location, resulting in an information integrity issue or an information leak.
> 
> - The application ends up running in an infinite loop or with severe degradation in performance despite the input sources having no such issue, resulting in a Denial of Service.  Note that correct but non-performant code is not a security issue candidate, this only applies to incorrect code that may result in performance degradation.

The last sentence somewhat contradicts the preceding one.  Perhaps "...may result in performance degradation severe enough to amount to a denial of service".

> - The application crashes due to the generated incorrect code, resulting in a Denial of Service.

	paul