RFC: Adding a SECURITY.md document to the Binutils
Siddhesh Poyarekar
siddhesh@gotplt.org
Wed Apr 12 17:10:01 GMT 2023
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
More information about the Gdb
mailing list