Re: RFC: Adding a SECURITY.md document to the Binutils

Siddhesh Poyarekar
2023-04-14T18:27:55Z

On 2023-04-14 13:37, Ian Lance Taylor wrote:
> On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-04-13 12:49, Paul Koning wrote:
>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>>
>> If someone sends me a C source file and I compile and link it without
>> inspecting it first, then definitely shame on me again. Compilers and
>> linkers assume *trusted* input.
>
> I profoundly disagree with this.

I should reiterate that this is not about robustness, it is about
treatment of bugs as security issues, i.e. by assigning CVEs and sending
out advisories to the larger user community. I am not arguing against
fixing bugs at all.

> Compilers and linkers must behave in a reasonable manner when given
> untrusted input. Behaving reasonably can of course include failing
> with an error message like "program too large", but they must not dump
> core and they must not use up all available memory. They very much
> must not have a buffer overflow during compilation that causes them to
> execute arbitrary code. Users should not be expected to run compilers

A compiler crash, core dump, etc. is definitely a serious bug and we
consider them as P1/P2 in almost all cases. However to be considered a
security issue, the input has to be crafted and that's where the user
comes in; their responsibility is to ensure that they don't build
untrusted code (e.g. when they're trying to study malware or virus
sources or binaries) outside of sandboxes.

The expectation is *not* that they always run compilers in a sandbox, it
is that they're aware of the code they're trying to compile and IMO it
is not an unreasonable expectation. The odds of even minimally trusted
code (like an upstream project) resulting in, e.g. overwriting or
corrupting some persistent state (like some file on disk) or sending out
private information due to a buffer overflow in gcc, ld, or even objdump
is near-zero. The code would have to be specially *crafted* (or the
operator being remarkably unlucky) to achieve that.

If as a project we decide to treat untrusted input as a valid use case,
it is going to shift the goalposts for binutils (and gcc, if we take the
same stand there). I suppose golang does try to adhere to these higher
standards somewhat but I am not well versed with their formal position
on this. I've seen them consider bugs due to untrusted regex inputs as
security issues whereas even glibc currently doesn't, except for some
very specific conditions.

The llvm project doesn't consider anything[1] a security issue at the
moment. I was told off-hand by a rust maintainer that the rust
community also pretty much aligns with the llvm position, but I don't
have a handy reference for it.

If binutils, gcc, etc. aspire to the levels of support that golang
provides, we need to do what the llvm community is currently doing, i.e.
form a security group and incrementally identify parts that we want to
identify as security sensitive and provide stronger security guarantees
for them. My previous suggestion to do that was discouraged[2], so if
that has changed today then we could move in that direction.

> and linkers in a security sandbox (though it would be acceptable for a
> compiler to set up its own security sandbox if that seems useful).

I suggested an --isolate flag for the analysis tools (objdump, etc.) to
do exactly this elsewhere in this thread.

Thanks,
Sid

[1] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue
[2] https://inbox.sourceware.org/binutils/YBD72RqjVomppMYS@vapier/