On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
> On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor <i...@google.com> wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > >> <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). 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.? Thanks, David