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.
