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

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

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