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

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