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

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

On 12/04/2023 18:10, Siddhesh Poyarekar wrote:
> 
> 
> On 2023-04-12 12:52, Richard Earnshaw wrote:
>>
>>
>> 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
> 
> Perhaps also name libbfd, libopcode, etc. in the libraries to make it 
> clearer.
> 
>>>>>     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.
> 
> OK, then how about this for the first paragraph:
> 
> ~~~
> A security bug is one that threatens the security of a system or 
> network.  In the context of GNU Binutils, there are two ways in which a 
> bug could have security consequences. The primary method is when the 
> tools introduce a vulnerability in the output file that was not present 
> in the input files being processed.  The other, albeit unlikely way is 
> when a bug in the tools results in a privilege boundary is crossed in 
> either the tools themselves or in the code they generate.

So mention of networks reminds me that you don't always need privilege 
escalation to have a security compromise - simply transmitting a file to 
a third party, if that wasn't intended, would be enough.

So I would suggest:

A security bug is one that threatens the security of a system or 
network, or might compromise the security of data stored on it.  In the 
context of GNU Binutils there are two ways in which such bugs might 
occur.  In the first, the programs themselves might be tricked into a 
direct compromise of security.  In the second, the tools might introduce 
a vulnerability in the generated output that was not already present in 
the files used as input.

Note: none of the programs in the GNU Binutils suite need elevated 
system privileges (eg setuid) to operate and we recommend that users do 
not use them from accounts where such privileges are automatically 
available.

R.

> ~~~
> 
>>>> 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.
> 
> Agreed, that sounds more precise.  I've incorporated that into the 
> paragraph above.  How does that sound overall?
> 
> Thanks,
> Sid