[PATCH 0/5] SECURITY.txt changes

[PATCH 0/5] SECURITY.txt changes

[Andrew Burgess]

Some changes to GDB's SECURITY.txt document.  Patches #3 and #4 are
related, but all the others are standalone.

Feedback welcome.

Thanks,
Andrew

---

Andrew Burgess (5):
  gdb: fix minor grammar error in SECURITY.txt
  gdb: extend SECURITY.txt to highlight additional remote debugging
    risks
  gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs
  gdb: in SECURITY.txt, add notes on reporting exec and debug bugs
  gdb: improve SECURITY.txt relating to embedded language bugs

 gdb/SECURITY.txt | 68 ++++++++++++++++++++++++++++++++----------------
 1 file changed, 46 insertions(+), 22 deletions(-)


base-commit: 506d153ed46c3b5ffe9041647a9d57faae8ec22c
-- 
2.25.4

[PATCH 1/5] gdb: fix minor grammar error in SECURITY.txt

[Andrew Burgess]

There's a missing 'to' in the SECURITY.txt document.  Fixed in this
commit.
---
 gdb/SECURITY.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index 008bf88d230..f4ddebe3f03 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -17,7 +17,7 @@ Introduction
 Policy Objectives
 -----------------
 
-  The objective of this policy is define what the GDB project
+  The objective of this policy is to define what the GDB project
   considers a security bug and what is a non-security bug, and how
   bugs can be reported.
 
-- 
2.25.4

Re: [PATCH 1/5] gdb: fix minor grammar error in SECURITY.txt

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> There's a missing 'to' in the SECURITY.txt document.  Fixed in this
Andrew> commit.

Seems obvious.
Approved-By: Tom Tromey <tom@tromey.com>

Tom

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

[Andrew Burgess]

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.
---
 gdb/SECURITY.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index f4ddebe3f03..63e110055db 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -210,6 +210,18 @@ 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.  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
 ---------------------------
 
-- 
2.25.4

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

[Siddhesh Poyarekar]

On 10/12/26 9:49 AM, Andrew Burgess wrote:
> 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.
> ---
>   gdb/SECURITY.txt | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
> index f4ddebe3f03..63e110055db 100644
> --- a/gdb/SECURITY.txt
> +++ b/gdb/SECURITY.txt
> @@ -210,6 +210,18 @@ 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

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.

> +  to GDB, resulting in any of the issues described above.  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
>   ---------------------------
>   

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

[Tom Tromey]

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

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

[Siddhesh Poyarekar]

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

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

[Andrew Burgess]

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

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

[Siddhesh Poyarekar]

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

[PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Andrew Burgess]

I believe there is some ambiguity in the SECURITY.txt file when it
comes to bugs within the DWARF and BFD parsing code.

Here are the relevant passages:

  Any bugs in GDB or gdbserver that result in an unexpected crossing
  of a privilege boundary are considered security bugs.  Some examples
  of crossing a privilege boundary include: being able to execute code
  as an arbitrarily different user, or accessing resources
  (e.g. files, sockets, etc) for which the original user would not
  normally have access.

And:

  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.

And later on:

  There are known bugs in GDB related to loading malformed executables
  and parsing the debug information, a consequence of these bugs is
  that a malicious program could trigger undefined behavior in GDB,
  which could be used to trigger arbitrary code execution.

  ...

  As there are already known bugs in GDB relating to undefined
  behavior triggered from malformed programs, further bugs in this
  area should still be reported, but are unlikely to be given high
  priority.  Bugs in GDB that are triggered by well-formed programs
  should also be reported, and are likely to be treated as higher
  priority as these are more likely to impact normal use of GDB.

I think this final paragraph is confusing.  Is a bug in the DWARF/BFD
parser a security issue or not?

I certainly have no desire to invite a deluge of security bugs
relating the DWARF/BFD parsing, nor am I volunteering to spend all my
time fixing these bugs.

But, given our definition of a security bug, I think we need to
acknowledge that DWARF/BFD parser bugs are security issues (if they
meet the earlier definition).  However, I do think we should be honest
about how likely these issues are to be fixed, i.e. not necessarily as
a high priority.

The changes I propose here then clarify this area:

  1. Clarify that the ideal is we'd like GDB to be bug free, but be
     firmer in saying that we believe there are bugs, and that these
     bugs could be security issues.

  2. Rewording, replace 'when using GDB with an untrusted binary' with
     'when examining or debugging an untrusted binary'.  This avoids
     repeating GDB and places the focus on the actions being performed.

  3. The real change: clearly state that bugs in the DWARF/BFD parser
     can be security bugs, but they are unlikely to be considered high
     priority, and users should instead use sandboxing to provide
     protection.  The text about bugs from well-formed programs is
     retained.
---
 gdb/SECURITY.txt | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index 63e110055db..533b70b5875 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -184,26 +184,30 @@ Security Realities Of The GDB Project
 
   When using GDB to examine, but not execute, an untrusted program
   (with gdbserver, the program will be started, but paused at the
-  first instruction and not run further), there should be no security
-  risks, however the GDB maintainers don't currently believe that GDB
-  or gdbserver is reliable enough to ensure that there are no security
-  risks.
+  first instruction and not run further), ideally there should be no
+  security risks.  However, there are known bugs in GDB related to
+  loading malformed executables and parsing the debug information, a
+  consequence of these bugs is that a malicious program could trigger
+  undefined behavior in GDB, which could be used to trigger arbitrary
+  code execution.  This means that even just loading an untrusted
+  executable into GDB, without executing the program, can pose a
+  security risk.
 
-  There are known bugs in GDB related to loading malformed executables
-  and parsing the debug information, a consequence of these bugs is
-  that a malicious program could trigger undefined behavior in GDB,
-  which could be used to trigger arbitrary code execution.
+  Given these risks, the advice of the GDB project is that, when
+  examining or debugging an untrusted binary, always do so in a
+  secure, sandboxed environment.
 
-  Given these risks, the advice of the GDB project is that, when using
-  GDB with an untrusted binary, always do so in a secure, sandboxed
-  environment.
-
-  As there are already known bugs in GDB relating to undefined
-  behavior triggered from malformed programs, further bugs in this
-  area should still be reported, but are unlikely to be given high
-  priority.  Bugs in GDB that are triggered by well-formed programs
-  should also be reported, and are likely to be treated as higher
-  priority as these are more likely to impact normal use of GDB.
+  Bugs related to parsing malformed executables and debug information
+  can meet the definition of a security bug as described in this
+  document.  However, the GDB project believes there are likely to be
+  many such bugs, and addressing all of them as high priority security
+  issues is not feasible given current project resources.  Users
+  should instead rely on sandboxing as the primary mitigation.  Bugs
+  in this area should still be reported through the normal bug
+  reporting process and will be addressed when possible.  Bugs in GDB
+  that are triggered by well-formed programs should also be reported,
+  and are likely to be treated as higher priority as these are more
+  likely to impact normal use of GDB.
 
   When using GDB and gdbserver to perform remote debug, the connection
   between the two components is by design insecure.  It is up to the
-- 
2.25.4

Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Siddhesh Poyarekar]

On 10/12/26 9:49 AM, Andrew Burgess wrote:
>    3. The real change: clearly state that bugs in the DWARF/BFD parser
>       can be security bugs, but they are unlikely to be considered high
>       priority, and users should instead use sandboxing to provide
>       protection.  The text about bugs from well-formed programs is
>       retained.
I don't have a strong opinion on the meat of the change, but I want to 
point out that this is not sufficient deterrence for people flooding the 
project with such reports to get CVE creds in their name.  What priority 
a CVE gets downstream is typically a result of perception and the 
relatively dumb CVSS scores.  Unfortunately all major distributions are 
currently lost to that madness and "unlikely to be considered high 
priority" may not actually pan out that way in practice.

Sid

Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Tom Tromey]

>>>>> Siddhesh Poyarekar <sipoyare@redhat.com> writes:

> On 10/12/26 9:49 AM, Andrew Burgess wrote:
>> 3. The real change: clearly state that bugs in the DWARF/BFD parser
>> can be security bugs, but they are unlikely to be considered high
>> priority, and users should instead use sandboxing to provide
>> protection.  The text about bugs from well-formed programs is
>> retained.

> I don't have a strong opinion on the meat of the change, but I want to
> point out that this is not sufficient deterrence for people flooding
> the project with such reports to get CVE creds in their name.  What
> priority a CVE gets downstream is typically a result of perception and
> the relatively dumb CVSS scores.  Unfortunately all major
> distributions are currently lost to that madness and "unlikely to be
> considered high priority" may not actually pan out that way in
> practice.

I agree but we can only control gdb, not what other projects do.  That
is, I think that CVEs are gamed dishonestly nowadays, but it's not clear
to me what other options we have for dealing with this.

Tom

Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Siddhesh Poyarekar]

n 10/14/26 11:12 AM, Tom Tromey wrote:
>>>>>> Siddhesh Poyarekar <sipoyare@redhat.com> writes:
> 
>> On 10/12/26 9:49 AM, Andrew Burgess wrote:
>>> 3. The real change: clearly state that bugs in the DWARF/BFD parser
>>> can be security bugs, but they are unlikely to be considered high
>>> priority, and users should instead use sandboxing to provide
>>> protection.  The text about bugs from well-formed programs is
>>> retained.
> 
>> I don't have a strong opinion on the meat of the change, but I want to
>> point out that this is not sufficient deterrence for people flooding
>> the project with such reports to get CVE creds in their name.  What
>> priority a CVE gets downstream is typically a result of perception and
>> the relatively dumb CVSS scores.  Unfortunately all major
>> distributions are currently lost to that madness and "unlikely to be
>> considered high priority" may not actually pan out that way in
>> practice.
> 
> I agree but we can only control gdb, not what other projects do.  That
> is, I think that CVEs are gamed dishonestly nowadays, but it's not clear
> to me what other options we have for dealing with this.
The glibc CNA plans to onboard the binutils project to the CNA program 
so that we can handle those and stem the CVE gaming for the project.  We 
could extend that to gdb too if there's interest, but we will need 
volunteers from the gdb team on the security team because the gdb 
security policy is a bit more complex to interpret than the binutils 
one, which assumes that all input as trusted.

Of course, we'd still need the policy to define what can be reasonably 
secured and exclude the rest from scope.

Sid

Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Carlos O'Donell]

On 10/14/26 12:16 PM, Siddhesh Poyarekar wrote:
> n 10/14/26 11:12 AM, Tom Tromey wrote:
>>>>>>> Siddhesh Poyarekar <sipoyare@redhat.com> writes:
>>> On 10/12/26 9:49 AM, Andrew Burgess wrote:
>>>> 3. The real change: clearly state that bugs in the DWARF/BFD parser
>>>> can be security bugs, but they are unlikely to be considered high 
>>>> priority, and users should instead use sandboxing to provide 
>>>> protection.  The text about bugs from well-formed programs is retained.
>> 
>>> I don't have a strong opinion on the meat of the change, but I want
>>> to point out that this is not sufficient deterrence for people
>>> flooding the project with such reports to get CVE creds in their
>>> name.  What priority a CVE gets downstream is typically a result of
>>> perception and the relatively dumb CVSS scores.  Unfortunately all
>>> major distributions are currently lost to that madness and
>>> "unlikely to be considered high priority" may not actually pan out
>>> that way in practice.
>> 
>> I agree but we can only control gdb, not what other projects do.
>> That is, I think that CVEs are gamed dishonestly nowadays, but it's
>> not clear to me what other options we have for dealing with this.
> The glibc CNA plans to onboard the binutils project to the CNA
> program so that we can handle those and stem the CVE gaming for the
> project.  We could extend that to gdb too if there's interest, but we
> will need volunteers from the gdb team on the security team because
> the gdb security policy is a bit more complex to interpret than the
> binutils one, which assumes that all input as trusted.

I'm happy to offer mentorship and training for anyone from the gdb
community that wants to join the security team.

It would help us better document onboarding and review policies :-) 
> Of course, we'd still need the policy to define what can be
> reasonably secured and exclude the rest from scope.

Agreed.

-- 
Cheers,
Carlos.

[PATCH 4/5] gdb: in SECURITY.txt, add notes on reporting exec and debug bugs

[Andrew Burgess]

The previous commit clarified the wording about bugs related to
parsing malformed executables and debug information.  Bugs in this
area can be security bugs, but will not be treated with high priority
by the GDB project.

Given this, it does not seem sensible to me that these bugs should be
reported via the more secret bug reporting path.  At the end of the
day fixing these bugs is unlikely to be a priority, so the bugs will
likely end up in the public bugzilla anyway.

I propose that we advise that these bugs just be added to the public
bugzilla from the start.

I'm aware that this advice might be a little contentious, and that is
why I've carved this change out from the previous one.  This makes it
easier for people to agree with the previous commit, but disagree with
this one.
---
 gdb/SECURITY.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index 533b70b5875..b484a1f65a1 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -238,6 +238,13 @@ Reporting Non-Security Bugs
 
     https://sourceware.org/bugzilla/
 
+  Bugs related to parsing malformed executables and debug information
+  should be reported through the public bugzilla.  This is an area of
+  GDB containing known bugs, and as discussed above, it is advised
+  that users mitigate these bugs by running within a sandboxed
+  environment.  As such, these bugs are considered to pose limited
+  risk to users.
+
 Reporting Security Bugs
 -----------------------
 
-- 
2.25.4

[PATCH 5/5] gdb: improve SECURITY.txt relating to embedded language bugs

[Andrew Burgess]

The SECURITY.txt document has some text about how GDB provides access
to Python, Guile, and Shell interpreters, and how security bugs are
only a GDB security bug if the bug is specifically caused by GDB's
implementation, rather than being a consequence of having access to
these languages.

However, the existing language was maybe not as clear as it could be.
Currently we say:

  "...and the effect can only be reproduced when executed in the GDB
  environment."

I think it is clearer if we instead say:

  "...and the effect is caused by a bug in GDB's implementation rather
  than being an inherent consequence of the executed code, or being a
  bug in the underlying language."

This tries to split the problem space into 3 cases:

  (1) A bug in the underlying language is not a GDB bug.

  (2) That GDB allows you to run harmful code via the extension
      languages is not a GDB bug.

  (3) A bug that only exists because of a bug in GDB's implementation
      of the extension languages is a GDB bug.
---
 gdb/SECURITY.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index b484a1f65a1..f4bcc656406 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -122,9 +122,10 @@ What Is Not A Security Bug
   GDB provides 3 different turing complete languages, Guile, Python
   and direct access to the shell.  Making use of these languages can
   have unknown effects, including outside of the GDB process.  Such
-  effects will only be considered security bugs if they fit some of the
-  definitions in this document and the effect can only be reproduced
-  when executed in the GDB environment.
+  effects will only be considered security bugs if they fit some of
+  the definitions in this document and the effect is caused by a bug
+  in GDB's implementation rather than being an inherent consequence of
+  the executed code, or being a bug in the underlying language.
 
   Any issues that arise from running an untrusted program outside of a
   secure environment are not security bugs in GDB.  Any issues that
-- 
2.25.4

Re: [PATCH 0/5] SECURITY.txt changes

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> Some changes to GDB's SECURITY.txt document.  Patches #3 and #4 are
Andrew> related, but all the others are standalone.

Andrew> Feedback welcome.

I read these and they all look fine to me.

Approved-By: Tom Tromey <tom@tromey.com>

I think it would be good to wait a bit before landing these in case
other people have comments.

thanks,
Tom