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

[Andrew Burgess <aburgess@redhat.com>]

Siddhesh Poyarekar <sipoyare@redhat.com> writes:

> 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.

Hi Siddhesh,

Thanks for your feedback.  I've added some additional text in this area
to hopefully clarify the issues you have highlighted.  The updated patch
#2 is below.

Thanks,
Andrew

---

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.
+
+  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
 ---------------------------