RFC: Updating the Binutils SECURITY.txt document

[Sam James]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20260506/689b8ee3/attachment.sig>