RFC: Updating the Binutils SECURITY.txt document

[Jan Beulich]

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