On 2023-08-08 10:14, David Edelsohn wrote:
On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <siddh...@gotplt.org
<mailto: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
<mailto:i...@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
