RFC: Updating the Binutils SECURITY.txt document

[Nick Clifton]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: security.txt.patch
Type: text/x-patch
Size: 2041 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20260506/bbbb3a4f/attachment-0001.bin>