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

On 2023-04-14 13:37, Ian Lance Taylor wrote:
> On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <[email protected]> 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/