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

On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <[email protected]> wrote:
>
> 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.

I believe I understand what you are saying, and I don't agree.

We live in a time where free software has succeeded.  People routinely
rely on gigantic libraries provided as source code by people across
the Internet.  10% of the projects on GitHub are written at least
partially in C++.  To argue that people should not even compile
untrusted code is to speak about a world that simply does not exist
today.  Very few people working on application level code can trust
their entire software supply chain.

This means that software development must be secure at every level.
We must not rely on the single layer of defense of trusting source
code, a defense that very few people can maintain.  We must defend at
other levels.

The binutils developers must play their own small part in this, which
is to assemble and link code correctly, and to not make the assembler,
linker, and related tools themselves into vectors for security issues.


> 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.

Yes, the Go project does aim to adhere to these higher standards,
because, in my opinion, they are the correct standards.

And, honestly, these are not standards that are unusually difficult to
meet.  Don't dump core, don't use up all of memory, don't have buffer
overflows.  Treat failures of this sort as security bugs to be fixed
ASAP in minor releases.  These are achievable goals.

Ian