Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-08-15 10:07, Alexander Monakov wrote:
> 
> On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> 
>> Does this as the first paragraph address your concerns:
> 
> Thanks, this is nicer (see notes below). My main concern is that we shouldn't
> pretend there's some method of verifying that arbitrary source code is "safe"
> to pass to an unsandboxed compiler, nor should we push the responsibility of
> doing that on users.

But responsibility would be pushed to users, wouldn't it?

>> 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 for safety.
> 
> The statement begins with "It is necessary", but the next statement offers
> an alternative in case the code is untrusted. This is a contradiction.
> Is it necessary or not in the end?
> 
> I'd suggest to drop this statement and instead make a brief note that
> compiling crafted/untrusted sources can result in arbitrary code execution
> and unconstrained resource consumption in the compiler.

So:

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.  Compiling untrusted sources can 
result in arbitrary code execution and unconstrained resource 
consumption in the compiler. As a result, compilation of such code 
should be done inside a sandboxed environment to ensure that it does not 
compromise the development environment.

>> For untrusted code should compilation should be done
>                       ^^^^^^
> 		     typo (spurious 'should')

Ack, thanks.

> 		
>> inside a sandboxed environment to ensure that it does not compromise the
>> development environment.  Note that this still does not guarantee safety of
>> the produced output programs and that such programs should still either be
>> analyzed thoroughly for safety or run only inside a sandbox or an isolated
>> system to avoid compromising the execution environment.
> 
> The last statement seems to be a new addition. It is too broad and again
> makes a reference to analysis that appears quite theoretical. It might be
> better to drop this (and instead talk in more specific terms about any
> guarantees that produced binary code matches security properties intended
> by the sources; I believe Richard Sandiford raised this previously).

OK, so I actually cover this at the end of the section; Richard's point 
AFAICT was about hardening, which I added another note for to make it 
explicit that missed hardening does not constitute a CVE-worthy threat:

     As a result, the only case for a potential security issue in the
     compiler is when it generates vulnerable application code for
     trusted input source code that is conforming to the relevant
     programming standard or extensions documented as supported by GCC
     and the algorithm expressed in the source code does not have the
     vulnerability.  The output application code could be considered
     vulnerable if it produces an actual vulnerability in the target
     application, specifically in the following cases:

     - 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 severe enough to amount to a denial of service.
     - The application crashes due to the generated incorrect code,
       resulting in a Denial of Service.