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

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

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.

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.

R.

> 
> Reporting private security bugs
> ===============================
> 
>    *All bugs reported in the Binutils Bugzilla are public.*
> 
>    In order to report a private security bug that is not immediately
>    public, please contact one of the downstream distributions with
>    security teams.  The follow teams have volunteered to handle such
>    bugs:
> 
>       Debian:  security@debian.org
>       Red Hat: secalert@redhat.com
>       SUSE:    security@suse.de
> 
>    Please report the bug to just one of these teams.  It will be shared
>    with other teams as necessary.
> 
>    The team contacted will take care of details such as vulnerability
>    rating and CVE assignment (http://cve.mitre.org/about/).  It is likely
>    that the team will ask to file a public bug because the issue is
>    sufficiently minor and does not warrant an embargo.  An embargo is not
>    a requirement for being credited with the discovery of a security
>    vulnerability.
> 
> Reporting public security bugs
> ==============================
> 
>    It is expected that critical security bugs will be rare, and that most
>    security bugs can be reported in Binutils Bugzilla system, thus making
>    them public immediately.  The system can be found here:
> 
>       https://sourceware.org/bugzilla/
> 
> ----------------------------------------------------------------------
> 
>    Thoughts ?  Comments ?
> 
> Cheers
>    Nick
>