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

[Tom Tromey <tom@tromey.com>]

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

Tom