[v4] gdb: Update SECURITY.txt to mention extension scripts and internal errors

  Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
the gdb/SECURITY.txt to be more explicit about some details. Specifically,
we now explicitly say that internal errors aren't security
vulnerabilities, and mention that users should review plugins before
running them, and under which conditions a plugin can cause a security
bug.

Reviewed-By: Luis Machado <luis.machado@arm.com>
---
 gdb/SECURITY.txt | 51 ++++++++++++++++++++++++++++++++++++------------
 1 file changed, 38 insertions(+), 13 deletions(-)
  

>>>>> Guinevere Larsen <blarsen@redhat.com> writes:

> Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
> the gdb/SECURITY.txt to be more explicit about some details. Specifically,
> we now explicitly say that internal errors aren't security
> vulnerabilities, and mention that users should review plugins before
> running them, and under which conditions a plugin can cause a security
> bug.

Thank you.

> +  control of the user and are always safe to load.  All of these files
> +  are treated as trusted input, meaning GDB makes no attempt to sanitize
> +  commands and has no sandboxing or other protections against effects of
> +  commands ran by any automatically loaded file.  It is up to the user to

I think I'd write "...effects of commands run by any...".
That is s/ran/run/

> +  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 targetting GDB itself, or other bugs that target
> +  this use case, are not considered a security bug.

Typo, "targeting".

I was considering that may be this section isn't fully correct, because
if a program is somehow specially crafted to make it impossible for gdb
to debug it, that is a bug.  However I suppose it isn't a security bug,
just an ordinary one.

Anyway I'm happy with the proposed text, and I'm happy to give my
approval, but I think perhaps others ought to read it as well before
checking it in.

Tom
  

On 9/25/24 2:03 PM, Tom Tromey wrote:
>>>>>> Guinevere Larsen <blarsen@redhat.com> writes:
>> Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
>> the gdb/SECURITY.txt to be more explicit about some details. Specifically,
>> we now explicitly say that internal errors aren't security
>> vulnerabilities, and mention that users should review plugins before
>> running them, and under which conditions a plugin can cause a security
>> bug.
> Thank you.
>
>> +  control of the user and are always safe to load.  All of these files
>> +  are treated as trusted input, meaning GDB makes no attempt to sanitize
>> +  commands and has no sandboxing or other protections against effects of
>> +  commands ran by any automatically loaded file.  It is up to the user to
> I think I'd write "...effects of commands run by any...".
> That is s/ran/run/
Ok, I'll change it.
>
>> +  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 targetting GDB itself, or other bugs that target
>> +  this use case, are not considered a security bug.
> Typo, "targeting".
thanks!
>
> I was considering that may be this section isn't fully correct, because
> if a program is somehow specially crafted to make it impossible for gdb
> to debug it, that is a bug.  However I suppose it isn't a security bug,
> just an ordinary one.
If I remember correctly, there are some ways to detect you're running 
under GDB and change behavior, making things undebuggable, so yeah, I 
think opening that opportunity for this to be considered a security bug 
is too broad.
>
> Anyway I'm happy with the proposed text, and I'm happy to give my
> approval, but I think perhaps others ought to read it as well before
> checking it in.
Ok. In the meantime, can I add your review tag?
>
> Tom
>
  

Just a couple nits.

On 9/17/24 19:58, Guinevere Larsen wrote:
> Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
> the gdb/SECURITY.txt to be more explicit about some details. Specifically,
> we now explicitly say that internal errors aren't security
> vulnerabilities, and mention that users should review plugins before
> running them, and under which conditions a plugin can cause a security
> bug.
> 
> Reviewed-By: Luis Machado <luis.machado@arm.com>
> ---
>  gdb/SECURITY.txt | 51 ++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
> index e483790349b..298c5ed26e0 100644
> --- a/gdb/SECURITY.txt
> +++ b/gdb/SECURITY.txt
> @@ -62,19 +62,25 @@ What Is A Security Bug?
>    (either from the GDB command line, a GDB configuration file, or from
>    the GDB prompt) are considered security bugs.
>  
> -  GDB will check for and load multiple configuration files.  When
> -  initially started GDB can load user- and system-specific
> -  configuration files, this is done unconditionally as it is assumed
> -  these files are under control of the user and are always safe to
> -  load.
> -
> -  GDB can also load per-project and per-program configuration files,
> -  this is done when a program to debug is loaded into GDB.  These
> -  configuration files will only be loaded if the user has given GDB
> -  permission to load these files.  Any bug in GDB which allows
> -  per-project or per-program configuration files to be loaded without
> -  permission having been granted by the user is considered a security
> -  bug.
> +  GDB will check for and load multiple configuration files, sometimes
> +  referred to as extension scripts or plugins.  When initially started
> +  GDB can load user-specific and/or system-specific configuration files,
> +  this is done unconditionally as it is assumed these files are under
> +  control of the user and are always safe to load.  All of these files
> +  are treated as trusted input, meaning GDB makes no attempt to sanitize
> +  commands and has no sandboxing or other protections against effects of
> +  commands ran by any automatically loaded file.  It is up to the user to
> +  audit files against documentation provided by the relevant projects to
> +  protect against malicious commands.  If executing commands provided by
> +  the GDB project generates undocumented side effects, this is a bug.  For
> +  that bug to be considered a security bug, it must meet other definitions
> +  of security bugs outlined in this document.
> +
> +  GDB can also load per-project and/or per-program configuration files
> +  when a program is loaded for debugging.  Such files will only be loaded
> +  if the user has given GDB permission to load them.  Any bug in GDB which
> +  allows per-project or per-program configuration files to be loaded without
> +  permission having been granted by the user is considered a security bug.
>  
>    When gdbserver is started, if it is passed a program on its command
>    line then that program will be started, but paused before executing
> @@ -101,6 +107,25 @@ What Is Not A Security Bug
>    In the context of local debugging, when GDB is used to execute a
>    program, the program runs with the same privileges as GDB itself.
>  
> +  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 targetting GDB itself, or other bugs that target
> +  this use case, are not considered a security bug.
> +
> +  By the same token, simply triggering an internal error in GDB is not
> +  considered a security bug, since GDB has detected an issue and
> +  handled it in a non-exploitable manner.  If it can be demonstrated
> +  that some bug other than the internal error happens, this other bug
> +  should be evaluated independently of the error, and may be a security
> +  bug if it fits some of the definitions in this document.
> +
> +  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 bug if they fit some of the

s/considered security bug/considered security bugs

> +  definitions defined in this document and the effect can only be

Maybe drop "defined" here. It still seems clear for me without it.

> +  reproduced when executed in the GDB environment.
> +
>    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

Reviewed-By: Luis Machado <luis.machado@arm.com>
  

On 9/26/24 3:07 AM, Luis Machado wrote:
> Just a couple nits.
>
> On 9/17/24 19:58, Guinevere Larsen wrote:
>> Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
>> the gdb/SECURITY.txt to be more explicit about some details. Specifically,
>> we now explicitly say that internal errors aren't security
>> vulnerabilities, and mention that users should review plugins before
>> running them, and under which conditions a plugin can cause a security
>> bug.
>>
>> Reviewed-By: Luis Machado <luis.machado@arm.com>
>> ---
>>   gdb/SECURITY.txt | 51 ++++++++++++++++++++++++++++++++++++------------
>>   1 file changed, 38 insertions(+), 13 deletions(-)
>>
>> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
>> index e483790349b..298c5ed26e0 100644
>> --- a/gdb/SECURITY.txt
>> +++ b/gdb/SECURITY.txt
>> @@ -62,19 +62,25 @@ What Is A Security Bug?
>>     (either from the GDB command line, a GDB configuration file, or from
>>     the GDB prompt) are considered security bugs.
>>   
>> -  GDB will check for and load multiple configuration files.  When
>> -  initially started GDB can load user- and system-specific
>> -  configuration files, this is done unconditionally as it is assumed
>> -  these files are under control of the user and are always safe to
>> -  load.
>> -
>> -  GDB can also load per-project and per-program configuration files,
>> -  this is done when a program to debug is loaded into GDB.  These
>> -  configuration files will only be loaded if the user has given GDB
>> -  permission to load these files.  Any bug in GDB which allows
>> -  per-project or per-program configuration files to be loaded without
>> -  permission having been granted by the user is considered a security
>> -  bug.
>> +  GDB will check for and load multiple configuration files, sometimes
>> +  referred to as extension scripts or plugins.  When initially started
>> +  GDB can load user-specific and/or system-specific configuration files,
>> +  this is done unconditionally as it is assumed these files are under
>> +  control of the user and are always safe to load.  All of these files
>> +  are treated as trusted input, meaning GDB makes no attempt to sanitize
>> +  commands and has no sandboxing or other protections against effects of
>> +  commands ran by any automatically loaded file.  It is up to the user to
>> +  audit files against documentation provided by the relevant projects to
>> +  protect against malicious commands.  If executing commands provided by
>> +  the GDB project generates undocumented side effects, this is a bug.  For
>> +  that bug to be considered a security bug, it must meet other definitions
>> +  of security bugs outlined in this document.
>> +
>> +  GDB can also load per-project and/or per-program configuration files
>> +  when a program is loaded for debugging.  Such files will only be loaded
>> +  if the user has given GDB permission to load them.  Any bug in GDB which
>> +  allows per-project or per-program configuration files to be loaded without
>> +  permission having been granted by the user is considered a security bug.
>>   
>>     When gdbserver is started, if it is passed a program on its command
>>     line then that program will be started, but paused before executing
>> @@ -101,6 +107,25 @@ What Is Not A Security Bug
>>     In the context of local debugging, when GDB is used to execute a
>>     program, the program runs with the same privileges as GDB itself.
>>   
>> +  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 targetting GDB itself, or other bugs that target
>> +  this use case, are not considered a security bug.
>> +
>> +  By the same token, simply triggering an internal error in GDB is not
>> +  considered a security bug, since GDB has detected an issue and
>> +  handled it in a non-exploitable manner.  If it can be demonstrated
>> +  that some bug other than the internal error happens, this other bug
>> +  should be evaluated independently of the error, and may be a security
>> +  bug if it fits some of the definitions in this document.
>> +
>> +  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 bug if they fit some of the
> s/considered security bug/considered security bugs
>
>> +  definitions defined in this document and the effect can only be
> Maybe drop "defined" here. It still seems clear for me without it.
>
>> +  reproduced when executed in the GDB environment.
>> +
>>     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
> Reviewed-By: Luis Machado <luis.machado@arm.com>
>
Thanks, I fixed all the nits!
  

>>>>> "Guinevere" == Guinevere Larsen <guinevere@redhat.com> writes:

>> Anyway I'm happy with the proposed text, and I'm happy to give my
>> approval, but I think perhaps others ought to read it as well before
>> checking it in.

Guinevere> Ok. In the meantime, can I add your review tag?

Definitely.  Thanks.

Tom