RFC: Updating the Binutils SECURITY.txt document

  Hi Guys,

  I want to update the SECURITY.txt document so that it makes clear that
  bugs that rely upon using a fuzzed binary to trigger an illegal memory
  access should not be considered as security bugs.

  This has been triggered by the fact that almost all binutils related
  CVEs in the last few years have been instances of fuzzed input
  crashing one tool or another.  So, in order to stop this I am
  proposing to add the following paragraph to the Notes section of the
  document:

    The tools assume that the input is to be trusted.  If this is not
    the case then the tools should be run inside a sandboxed
    environment to ensure that they do not compromise the host
    environment.  In the context of this document then a bug which
    relies upon using untrusted input, eg a crafted binary, must show
    that the result is a breach of trust boundary, e.g. being able to
    execute code as another user or root, or escape from the sandboxed
    environment.  If this is not possible then the bug will not be
    considered a security bug.

  In addition I want to make clear that the binutils tools are not
  intended to provide any kind of network accessible service, and hence
  cannot be part of a denial of service attack.  So I am also looking to
  add the following paragraph:
    
    All the tools in binutils are command line programs or internal
    libraries used to build those programs.  None of them are intended
    to provide a network accessible service.

  Lastly, in order to make clear what is meant by "a direct compromise of
  security", I am planning on changing these sentences:

    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.

  To:

    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, allowing operations
    with elevated or unauthorized permissions than the executing
    user. 

  Full patch attached.

  Any comments, questions or suggestions ?

Cheers
  Nick
  

On 06.05.2026 13:01, Nick Clifton wrote:
> Hi Guys,
> 
>   I want to update the SECURITY.txt document so that it makes clear that
>   bugs that rely upon using a fuzzed binary to trigger an illegal memory
>   access should not be considered as security bugs.
> 
>   This has been triggered by the fact that almost all binutils related
>   CVEs in the last few years have been instances of fuzzed input
>   crashing one tool or another.  So, in order to stop this I am
>   proposing to add the following paragraph to the Notes section of the
>   document:
> 
>     The tools assume that the input is to be trusted.  If this is not
>     the case then the tools should be run inside a sandboxed
>     environment to ensure that they do not compromise the host
>     environment.  In the context of this document then a bug which
>     relies upon using untrusted input, eg a crafted binary, must show
>     that the result is a breach of trust boundary, e.g. being able to
>     execute code as another user or root, or escape from the sandboxed
>     environment.  If this is not possible then the bug will not be
>     considered a security bug.
> 
>   In addition I want to make clear that the binutils tools are not
>   intended to provide any kind of network accessible service, and hence
>   cannot be part of a denial of service attack.  So I am also looking to
>   add the following paragraph:
>     
>     All the tools in binutils are command line programs or internal
>     libraries used to build those programs.  None of them are intended
>     to provide a network accessible service.
> 
>   Lastly, in order to make clear what is meant by "a direct compromise of
>   security", I am planning on changing these sentences:
> 
>     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.
> 
>   To:
> 
>     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, allowing operations
>     with elevated or unauthorized permissions than the executing
>     user. 
> 
>   Full patch attached.
> 
>   Any comments, questions or suggestions ?

Very simple: Please go ahead.

Jan
  

Nick Clifton <nickc@redhat.com> writes:

> Hi Guys,
>
>   I want to update the SECURITY.txt document so that it makes clear that
>   bugs that rely upon using a fuzzed binary to trigger an illegal memory
>   access should not be considered as security bugs.
>
>   This has been triggered by the fact that almost all binutils related
>   CVEs in the last few years have been instances of fuzzed input
>   crashing one tool or another.  So, in order to stop this I am
>   proposing to add the following paragraph to the Notes section of the
>   document:
>
>     The tools assume that the input is to be trusted.  If this is not
>     the case then the tools should be run inside a sandboxed
>     environment to ensure that they do not compromise the host
>     environment.  In the context of this document then a bug which
>     relies upon using untrusted input, eg a crafted binary, must show
>     that the result is a breach of trust boundary, e.g. being able to
>     execute code as another user or root, or escape from the sandboxed
>     environment.  If this is not possible then the bug will not be
>     considered a security bug.
>
>   In addition I want to make clear that the binutils tools are not
>   intended to provide any kind of network accessible service, and hence
>   cannot be part of a denial of service attack.  So I am also looking to
>   add the following paragraph:
>     
>     All the tools in binutils are command line programs or internal
>     libraries used to build those programs.  None of them are intended
>     to provide a network accessible service.
>
>   Lastly, in order to make clear what is meant by "a direct compromise of
>   security", I am planning on changing these sentences:
>
>     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.
>
>   To:
>
>     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, allowing operations
>     with elevated or unauthorized permissions than the executing
>     user. 
>
>   Full patch attached.
>
>   Any comments, questions or suggestions ?

Yes please, and thank you for doing this.

> [...]

sam