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

Siddhesh Poyarekar
2023-04-12T16:26:47Z

On 2023-04-12 12:02, Richard Earnshaw wrote:
>
>
> On 07/04/2023 09:42, Nick Clifton via Binutils wrote:
>> Hi Guys,
>>
>>    Many open source projects have a SECURITY.md file which explains
>>    their stance on security related bugs.  So I thought that it would
>>    be a good idea if we had one too.  The top level file would actually
>>    just be a placeholder, like this:
>>
>> ------------- ./SECURITY.md ------------------------------------------
>> For details on the Binutils security process please see
>> the SECURITY.md file in the binutils sub-directory.
>>
>> For details on the GDB security process please see
>> the SECURITY.md file in the gdb sub-directory.
>> --------------------------------------------------------------------
>>
>>    So this email is mostly about the wording for the Binutils specific
>>    version.  Here is my current proposal:
>>
>> ---------------- binutils/SECURITY.md ------------------------------
>> Binutils Security Process
>> =========================
>>
>> What is a binutils security bug?
>> ================================
>>
>>     A security bug is one that threatens the security of a system or
>>     network.  In the context of the GNU Binutils this means a bug that
>>     relates to the creation of corrupt output files from valid, trusted
>>     inputs.  Even then the bug would only have a security impact if the
>>     the code invokes undefined behaviour or results in a privilege
>>     boundary being crossed.
>>
>>     Other than that, all other bugs will be treated as non-security
>>     issues.  This does not mean that they will be ignored, just that
>>     they will not be given the priority that is given to security bugs.
>>
>>     This stance applies to the creation tools in the GNU Binutils (eg
>>     as, ld, gold, objcopy) and the libraries that they use.  Bugs in
>>     inspection tools (eg readelf, nm objdump) will not be considered
>>     to be security bugs, since they do not create executable output
>>     files.  When used on untrusted inputs, these inspection tools
>>     should be appropriately sandboxed to mitigate potential damage
>>     due to any malicious input files.
>
> I'd expect that any program used on untrusted input to be run only at
> user-level privileges.  So we should exclude issues where an account
> with elevated privileges (eg root) is used with either inspection or
> generation tools.

Agreed, I think this should be addressed by the "or results in a
privilege boundary being crossed". By running these programs as root,
the user is elevating privileges themselves, so it's not a binutils problem.

Perhaps it's necessary to educate users to not run these programs as
root, but I don't think it is the intent of SECURITY.md to educate users
about secure usage. The intent is to define context by describing what
constitutes security-relevant bugs and then document mechanisms to reach
out to communicate those bugs in case they're sensitive.

> The other area of concern is where the tools (particularly the linker)
> 'generate' code; so bugs in the opcodes the assembler generates (eg by
> not setting some don't care bits to something safe) or with code
> generated by the linker to glue functions together (relocation handling,
> PLTs, veneers, etc) would also count.

Ack, I reckon this should be addressed by "corrupt output files from
valid trusted inputs". If that's not clear enough, could you suggest
alternative phrasing that makes it clearer?

Thanks,
Sid