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

Siddhesh Poyarekar
2023-04-14T21:25:19Z

On 2023-04-14 16:46, Ian Lance Taylor wrote:
> On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> 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.

I don't disagree with that as an end goal (I even suggested that in that
previous thread last year), I think our disagreement is in how we get
there in terms of policy, which is a result of that conversation from
last year and from exploring how llvm and rust are handling it.

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

Sure, they're achievable with adequate resources, but I'm not sure if
the binutils project has that; that was in essence the conclusion of
last year's conversation FWIW. That of course is a question for the
maintainers of the project.

Thanks,
Sid