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

[Luis Machado]

CC-ing Eli for some proper english input.

Sorry for the delay.

On 6/14/24 20:41, 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.
> ---
> Changes for v2:
>   * Integrated the part talking about plugins with the paragraph that
>     mentions configuration files, as they work the same in this context.
>   * Reworded what is a security bug when executing a script.
>   * Changed denial of service text to explain why denial of service
>     doesn't matter, and add the exception of when it does.
>   * Split Internal error section into it's own paragraph, and mention
>     when an internal error may still have a security issue.
>   * Split off the part talking about obviously malicious commands in
>     scripts, and placed it in the "What is Not A Security Bug" section.
> ---
>  gdb/SECURITY.txt | 47 +++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 37 insertions(+), 10 deletions(-)
> 
> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
> index e483790349b..df9b91d9f72 100644
> --- a/gdb/SECURITY.txt
> +++ b/gdb/SECURITY.txt
> @@ -62,16 +62,23 @@ 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
> +  GDB will check for and load multiple configuration files and extension
> +  scripts or plugins.  When initially started GDB can load user- and

nit

I'd say user-specific as well:

user-specific and /or system-specific

> +  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 these files are treated as trusted input, meaning

s/All these/All of these?

> +  GDB makes no attempt sanitize commands and has no sandboxing or other

s/attempt sanitize/attempt to sanitize

> +  protections against intended effects of commands ran by any
> +  automatically loaded file.  It is up to the user to audit files against

s/automatically loaded/automatically-loaded

> +  documentation provided by the relevant projects to protect against
> +  malicious commands.  If executing commands provided by GDB or one of its
> +  submodules generates undocumented side effects that can be exploited by
> +  an attacker, it may be considered a security bug.
> +
> +  GDB can also load per-project and per-program configuration files or

and -> and/or

> +  scripts, this is done when a program to debug is loaded into GDB.

I'd rephrase it as...

scripts when a program is loaded for debugging.

> +  These configuration files will only be loaded if the user has given
> +  GDB permission to load these files.  Any bug in GDB which allows

s/these files/such files?

>    per-project or per-program configuration files to be loaded without
>    permission having been granted by the user is considered a security
>    bug.
> @@ -101,6 +108,26 @@ 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 targeting GDB itself are not considered security
> +  bugs.  If a GDB bug leads to another part of the system being
> +  partially or entirely unavailable, that bug may be considered a
> +  security bug.
> +
> +  By the same token, simply triggering an Internal Error in GDB is not

s/Internal Error/internal error?

> +  considered a security bug, since GDB has detected that an issue in
> +  internal code has happened and graciously handled it in a
> +  non-exploitable manner.  If the reporter can demonstrate that some
> +  bug other than the Internal Error happens, this other bug should be

Same as above.

> +  evaluated independently of the Error, and may be a security bug if it

s/Error/error?

> +  fits some of the definitions in this document.
> +
> +  GDB provides 3 different turing complete languages, guile, Python
> +  and direct access to the shell.  Being able to execute commands
> +  with documented effects that could be considered malicious in a
> +  configuration or extension script is 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

Otherwise the text update looks reasonable to me. It would be nice to have
some additional feedback from others.

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