Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-08-08 10:14, David Edelsohn wrote:
> On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <siddhesh@gotplt.org 
> <mailto:siddhesh@gotplt.org>> wrote:
> 
>     On 2023-08-08 10:04, Richard Biener wrote:
>      > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor <iant@google.com
>     <mailto:iant@google.com>> wrote:
>      >>
>      >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches
>      >> <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote:
>      >>>
>      >>> On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via
>     Gcc-patches wrote:
>      >>>> There's probably external tools to do this, not sure if we
>     should replicate
>      >>>> things in the driver for this.
>      >>>>
>      >>>> But sure, I think the driver is the proper point to address
>     any of such
>      >>>> issues - iff we want to address them at all.  Maybe a nice little
>      >>>> google summer-of-code project ;)
>      >>>
>      >>> What I'd really like to avoid is having all compiler bugs
>     (primarily ICEs)
>      >>> considered to be security bugs (e.g. DoS category), it would be
>     terrible to
>      >>> release every week a new compiler because of the "security" issues.
>      >>> Running compiler on untrusted sources can trigger ICEs (which
>     we want to fix
>      >>> but there will always be some), or run into some compile time
>     and/or compile
>      >>> memory issue (we have various quadratic or worse spots),
>     compiler stack
>      >>> limits (deeply nested stuff e.g. during parsing but other areas
>     as well).
>      >>> So, people running fuzzers and reporting issues is great, but
>     if they'd get
>      >>> a CVE assigned for each ice-on-invalid-code, ice-on-valid-code,
>      >>> each compile-time-hog and each memory-hog, that wouldn't be useful.
>      >>> Runtime libraries or security issues in the code we generate
>     for valid
>      >>> sources are of course a different thing.
>      >>
>      >>
>      >> I wonder if a security policy should say something about the
>     -fplugin
>      >> option.  I agree that an ICE is not a security issue, but I
>     wonder how
>      >> many people are aware that a poorly chosen command line option can
>      >> direct the compiler to run arbitrary code.  For that matter the same
>      >> is true of setting the GCC_EXEC_PREFIX environment variable, and no
>      >> doubt several other environment variables.  My point is not that we
>      >> should change these, but that a security policy should draw
>     attention
>      >> to the fact that there are cases in which the compiler will
>      >> unexpectedly run other programs.
>      >
>      > Well, if you run an arbitrary commandline from the internet you get
>      > what you deserve, running "echo "Hello World" | gcc -xc - -o
>     /dev/sda"
>      > as root doesn't need plugins to shoot yourself in the foot.  You
>     need to
>      > know what you're doing, otherwise you are basically executing an
>      > arbitrary shell script with whatever privileges you have.
> 
>     I think it would be useful to mention caveats with plugins though, just
>     like it would be useful to mention exceptions for libiberty and similar
>     libraries that gcc builds.  It only helps makes things clearer in terms
>     of what security coverage the project provides.
> 
> 
> I have added a line to the Note section in the proposed text:
> 
>      GCC and its tools provide features and options that can run 
> arbitrary user code (e.g., -fplugin).

How about the following to make it clearer that arbitrary code in 
plugins is not considered secure:

GCC and its tools provide features and options that can run arbitrary 
user code, e.g. using the -fplugin options.  Such custom code should be 
vetted by the user for safety as bugs exposed through such code will not 
be considered security issues.

> I believe that the security implication already is addressed because the 
> program is not tricked into a direct compromise of security.
> 
> 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.

Thanks,
Sid