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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 12/04/2023 17:26, Siddhesh Poyarekar wrote:
> 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.

My reading of the text is that "privilege boundary being crossed" (in 
the first paragraph) is specifically related to the generated output, 
not to the program itself being run with elevated privileges.

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

I'm not sure corrupt is general enough.  Each instruction in the binary 
might be completely legal, but their sequencing could leave some 
vulnerabilities (think spectre, for example, but that's pretty extreme).

Perhaps something like "... this means that the tools introduce a 
vulnerability in the output file that was not present in the input files 
being processed".  I think with that wording you probably don't even 
need the last sentence in the first paragraph.

R.

> 
> Thanks,
> Sid