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

[Siddhesh Poyarekar <sipoyare@redhat.com>]

On 10/14/26 11:08 AM, Tom Tromey wrote:
>>> +  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
> 
>> This is a good guideline, but does not make clear if bugs in this
>> processing will be treated as security issues.  This is true for the
>> line above as well, which this paragraph intends to augment - it warns
>> the user that such behaviour is not good, but does not make a
>> definitive statement whether bugs related to them will be treated as
>> security issues or not.
> 
> I think it's relatively clear given these paragraphs:
> 
>    GDB is not meant to be offered as a service (that is, offered
>    over an insecure connection to non-local users), and so denial of
>    service attacks targeting GDB itself, or other bugs that target
>    this use case, are not considered a security bug.
> ...
>    Any issues that arise from running an untrusted program outside of a
>    secure environment are not security bugs in GDB.  Any issues that
>    arise from running an untrusted program through GDB inside a secure
>    environment are only security bugs if GDB is required in order to
>    trigger the issue.
It's probably this clause that applies instead of the second one though, 
since it's about loading an executable without running it:

   Any bug in GDB or gdbserver that can trigger arbitrary code
   execution without the program being debugged having been executed by
   a user command, is considered a security bug, e.g. if loading a
   program into GDB could trigger arbitrary code execution, then this
   is a security issue.

except that the "if the remote target is untrusted" brings a new 
variable into the picture.  The policy assumes a trusted connection (the 
first clause you quoted) but an untrusted target (the new clause), i.e. 
an untrusted endpoint, which makes it moot.  This inconsistency leaves a 
gap in what's considered a security issue.

Sid