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

[Guinevere Larsen]

On 9/4/24 9:56 AM, Andrew Burgess wrote:
> Hi Guinevere,
>
> Thanks for continuing to work on this.  I'd like to see these
> improvements merged, but I do have some thoughts...
>
> 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.
>>
>> Reviewed-By: Luis Machado <luis.machado@arm.com>
>> ---
>>   gdb/SECURITY.txt | 51 ++++++++++++++++++++++++++++++++++++------------
>>   1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
>> index e483790349b..d5976a44cd5 100644
>> --- a/gdb/SECURITY.txt
>> +++ b/gdb/SECURITY.txt
>> @@ -62,20 +62,27 @@ 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
>> +  GDB will check for and load multiple configuration files and extension
>> +  scripts or plugins.
> Personally I'm not keen on wording that makes it sound like
> configuration files, scripts, and plugins are all different things.  I
> think it would be simpler if we instead mention once that these things
> are all just different names for the same thing, e.g:
>
>    GDB will check for and load multiple configuration files, sometimes
>    referred to as extension scripts, or plugins.
>
> Then after this, all the references to configuration files implicitly
> cover all these things.
>
> If you feel these are not all the same then maybe you could explain what
> the differences are.
I'm ok with this change.
>
>> +                        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 intended effects of
> I think we should drop 'intended' here.  There's no protection against
> _any_ effects, intended or not, right?  Now we do explain later that if
> there are unintended effects, then this is a bug (security or not).  But
> protection, there is none.

That's a fair point. I was thinking that the protection for unintended 
side effects were us fixing gdb :)

I'll make this change

>
>> +  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 GDB or one of its submodules generates undocumented side effects
>> +  that can be exploited by an attacker, it may be considered a security
> I think I'd change this last sentence to something like:
>
>    If executing commands provided by the GDB project generates
>    undocumented side effects then this is a bug.  If the bug meets the
>    definition of a security bug, then it is a security bug.
>
> The talk of submodules seems maybe Python specific and unnecessary at
> this level.
>
> I worry that the second sentence might be a bit circular, but I wanted
> to cover two cases:

I think we can make the sentence less circular by wording like this:

   If executing commands provided by the GDB project generates
   undocumented side effects, then 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.

If you don't like it, or I missed something, I'm fine with your version.

>
>    - A GDB extension language command that has undocumented side effects
>      is a bug.  Always.  But is not necessarily a security bug.
>
>    - The undocumented side effects might be a security bug if it meets
>      the definition we've laid out in this document.
>
> I deliberately dropper the 'can be exploited by an attacker' phrase as
> this seems to open up a whole new definition for what might, or might
> not be a security bug.  In the rest of the document we try to be quite
> specific about what defines a security bug, but this seems very open to
> interpretation.
This makes sense, I'll drop that wording.
>
>>     bug.
>>   
>> +  GDB can also load per-project and/or per-program configuration files
>> +  or scripts when a program is loaded for debugging.  Such files will
> So if we take my suggestion about then the mention of 'scripts' here is
> no longer needed.  If my suggestion is rejected then we're missing
> reference to 'plugins' here.
Will drop the mention of scripts.
>
>> +  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
>>     its first instruction.
>> @@ -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.
> Do we really want to add this last sentence here?  E.g. if I ask GDB to
> load a large binary that can cause GDB to consume lots of memory.  So if
> I offer GDB as a service, and an "attacker" then asks GDB to load a
> large binary, and GDB consumes all system memory, which triggers the
> kernel to OOM some other process ... is that a security issue in GDB?

At the top of the paragraph, I say GDB is not meant to be offered as a 
service. If you do offer it, it is user error, we shouldn't take that 
situation into account when deciding if something is a security bug.

>
> Would we even want to classify that as a security bug in a local GDB?

I wouldn't want to classify it as a security bug anywhere, and that's 
why I said "may be considered" instead of asserting it is.

>
> I'd rather we said the opposite; that if GDB is offered as a service
> then bugs in GDB which trigger DOS against other parts of a system are
> NOT security bugs.
I guess I should reword it to make it more obvious that GDB as a service 
is not something we care about in security terms, do it at your own risk 
or better yet, don't do it.
>
> For local usage of GDB, I think we're already covered.  We already say
> that any undocumented side effects of a GDB command are a bug.  But
> mostly I'd like to avoid accidentally classifying GDB consuming excess
> memory as anything other than a "bug".
That's fair. I wanted to cover for a crazy thing where GDB could, I 
don't know, kill the graphical environment or some important daemons. 
But when I tried to think of possible scenarios, it was always covered 
by other scenarios like unintended side effects or arbitrary code 
execution, so I am ok with dropping until I'm proven wrong.
>
>> +
>> +  By the same token, simply triggering an Internal Error in GDB is not
>> +  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.
> I think I'd simplify the back half of this sentence to just:
>
>     since GDB has detected an issue and has handled it in a
>     non-exploitable manner.
>
> I think 'internal code' is redundant, it doesn't really matter where GDB
> detected the issue, the issue was detected.
>
> The 'graciously' sounds odd here, my brain says 'gracefully' would
> possibly sound better... but both seem to imply some sort of neat
> handling of the issue, which I don't think hard terminating GDB is.  Now
> GDB's error() calls I would suggest are GDB gracefully handling an error
> condition .... but internal_error()... that's just a hard stop.
Fair point. I was thinking it was much more gracefully than a segfault, 
but you're right that it isn't particularly nice either.
>
>> +                            If the reporter can demonstrate that some
> I'd prefer 'If it can be demonstrated that ....' to avoid the
> implication that it's necessarily the reporters job.
I did this somewhat on purpose, since I don't want this to be tacitly 
accepted as our job to demonstrate this stuff. If someone wishes to 
claim something to be a security issue, they should be the ones showing 
that things can happen there. If you feel too strongly about this I can 
change it, but I would really want to avoid us having another job to 
deal with the fake CVEs.
>
>> +  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
> If we're not saying 'Internal Error' (not a fan of the capitalisation,
> but I think this was requested on v2, so I can live with it), then I
> think we should not capitalise 'Error' on its own.
Both you and Luis don't like the capitalization, I'll just remove it.
>
>> +  fits some of the definitions in this document.
>> +
>> +  GDB provides 3 different turing complete languages, guile, Python
> Looking at https://www.gnu.org/software/guile/ they appear to capitalise
> Guile (e.g. 'With Guile you can create ....') so I think we should too.
Will fix.
>
>> +  and direct access to the shell.  Being able to execute commands
>> +  with documented effects that could be considered malicious in a
> I don't think we want to imply that something is or isn't a security bug
> in GDB based on the documentation, or lack of, in some other project.
>
>    Making use of these languages can have unknown effects, including
>    outside of the GDB process.  If a security issue is caused by running
>    a command using one of these languages then that issue should be
>    filed with the appropriate project.

What I wanted to get at was that someone running "rm -rf /" using GDB 
was not a security issue because the code is obviously doing something 
malicious, but if some command like "echo 'stop'" was poorly handled by 
GDB and that could cause rm -rf to be called, we would consider this a 
security problem. Specifically, if GDB dealing with the command does 
something wrong that other interpreters don't do wrong, it is on us to fix

The text you offered doesn't cover that, but I think it can be reworded 
to fit that as well, something like:

   Making use of these languages can have unknown effects, including
   outside of the GDB process.  If a security issue is caused by running a
   command using one of these languages, it will only be considered a GDB
   bug if the effect is not present in other interpreters of this language.
   Otherwise it should be filed with the appropriate project.

What do you think?

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>
> Thanks,
> Andrew
>
>
>> +  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
>> -- 
>> 2.45.2