Re: [PATCH 2/5] gdb: extend SECURITY.txt to highlight additional remote debugging risks

[Siddhesh Poyarekar <sipoyare@redhat.com>]

On 10/16/26 10:24 AM, Andrew Burgess wrote:
> commit 2879d94ad12bae33908f1fc967c79f59ee97919a
> Author: Andrew Burgess <aburgess@redhat.com>
> Date:   Mon Oct 5 14:14:05 2026 +0100
> 
>      gdb: extend SECURITY.txt to highlight additional remote debugging risks
>      
>      I had cause to re-read the SECURITY.txt document recently, and I felt
>      that it wasn't really clear on one aspect of using GDB with gdbserver
>      (or any remote target).
>      
>      I felt that the text wasn't explicit enough about how a remote target
>      can download executables and libraries to GDB, and how GDB can then
>      parse these files.  When we consider the sort of bugs we see,
>      especially in BFD and the DWARF parser, when it comes to badly
>      formatted files, I thought it was worth calling this out.
> 
> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
> index f4ddebe3f03..64d68f88b84 100644
> --- a/gdb/SECURITY.txt
> +++ b/gdb/SECURITY.txt
> @@ -210,6 +210,28 @@ Security Realities Of The GDB Project
>     user to protect this connection, for example, by only starting
>     gdbserver within a secure network.
>   
> +  Additionally, when GDB connects to a remote target, it will, by
> +  default, automatically download the executable and shared libraries
> +  from the remote system and parse them locally, without prompting the
> +  user.  This means that the risks described above relating to parsing
> +  malformed executables also apply when performing remote debugging.
> +
> +  If the remote target is untrusted, or the connection to the remote
> +  target is untrusted, malicious or malformed binaries could be served
> +  to GDB, resulting in any of the issues described above.  Any bugs in
> +  GDB triggered by such files are evaluated against the definitions in
> +  this document independently of how the files were obtained.
> +
> +  Any bug related to remote debugging, whether the remote connection
> +  or target is trusted or not, is a security bug if the bug meets the
> +  other definitions in this document.  If an untrusted remote target,
> +  or use of an untrusted connection makes use of a documented GDB
> +  behaviour, then this is not a security bug in GDB.

That closes the gap, thanks.

Sid

> +
> +  Users should apply the same precautions when performing remote
> +  debugging as when analysing an untrusted binary locally, including
> +  running GDB in a secure, sandboxed environment.
> +
>   Reporting Non-Security Bugs
>   ---------------------------
>