Re: [RFC] Adding a SECURITY policy for GDB

[Andrew Burgess <aburgess@redhat.com>]

Eli,

Thanks for all your feedback.  Sorry it's taken me so long to get back
around to looking at this.  Most of the issues you highlighted are
straight forward fixes, but I do have a couple of follow up questions,
see inline below...

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>, Kevin Buettner
>>  <kevinb@redhat.com>, Simon Marchi <simark@simark.ca>,
>>  felix.willgerodt@intel.com, Paul Koning <paulkoning@comcast.net>
>> Date: Fri, 08 Dec 2023 15:05:35 +0000
>> 
>>   Remote debugging uses GDB to connect to a remote target.  GDB sends
>>   commands to the remote target which then controls the remote target.
>
> The last sentence above has some kind of typo in it: it basically says
> that "remote target controls the remote target", which makes no sense.
>
> So either "controls" should be "control" (plural), which would then
> mean it refers to "commands", or the sentence should be reworded to
> clarify the meaning (perhaps it conflated between gdbserver and the
> program it controls?)
>
>>   Other projects also implement remote targets to which GDB can
>>   connect.  Any bugs in these remote targets are out of scope for this
>>   policy and should be reported to the relevant project.  Any bugs in
>>   GDB caused by a misbehaving remote target, even when that target is
>>   not gdbserver, are in scope for this policy.
>
> I suggest to prepend "However," to the last sentence, to make it clear
> that it is contrary to the sentence before it.
>
>>   In the context of local debugging, when GDB is used to execute a
>>   program, the program runs with the same privileges as GDB itself.
>>   Running a program through GDB is no different than running a program
>>   directly.  If debugging an untrusted program then the user should
>>   ensure that this is done in a secure environment.
>
> Suggest to reword the last two sentence into one:
>
>   Since running a program through GDB is no different from running a
>   program directly, it follows that when debugging an untrusted
>   program, the user should ensure that this is done in a secure
>   environment.
>
>>                                                      Additionally, it
>>   is possible for a program to detect when it is run under GDB and to
>>   change its behaviour, unwanted behaviour may only appear when a
>>   program is run under GDB.
>
> I don't think I understand what this attempts to say.  Maybe this
> sentence should be moved to after the previous one.  Like this:
>
>   Running a program through GDB is no different than running a program
>   directly.  Additionally, it is possible for a program to detect when
>   it is run under GDB and to change its behavior, so that the unwanted
>   behavior may only appear when a program is run under GDB.
>   Therefore, when debugging an untrusted program, the user should
>   ensure that this is done in a secure environment.
>
>>   Any issues that arise from running an untrusted binary are not
>>   security bugs in GDB.
>
> This is too general, I think.  Perhaps you meant
>
>   Any issues that arise from running an untrusted binary not inside a
>   secure environment are not security bugs in GDB.
>
>>   In the context of remote debugging, the program being debugged is
>>   run with the same privileges as gdbserver.  As with GDB in the local
>>   debugging case, any issues that arise from running an untrusted
>>   binary via gdbserver are not not security bugs in gdbserver.
>
> Same here: too general?
>
>>   The connection between GDB and a remote target is not protected by
>>   either authentication, or encryption.
>                          ^
> That comma is redundant and should be deleted.
>
>>                                         Connecting to a remote target
>>   allows for arbitrary code execution on the remote system with the
>>   same privileges as the remote user, and any resource that the remote
>>   user can access can be read by GDB, and downloaded to the local
>>   machine on which GDB is running.  As such users need to take
>>   independent measures to secure the connection between GDB and the
>>   remote target.
>
> There should be a comma after "As such" in the last sentence,
> otherwise it reads as an incomplete sentence.
>
>>   Any issues that arise due to a failure to protect the connection
>>   between GDB and a remote target are not security bugs.
>                                     ^^^^^^^^^^^^^^^^^^^^^
> "are not security bugs in GDB."
>
>>   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
>                                             ^
> That semi-colon should be a colon.
>
>>   Any bugs in GDB that result in execution of the program being
>>   debugged without a user issued GDB command triggering execution
>                             ^^^^^^
> "issuing"
>
>>   (either from the GDB command line, a GDB configuration file, or from
>>   the GDB prompt) are considered security bugs.
>
> Is any execution of the program triggered by starting GDB considered
> "a command issued by the user"?  IOW, are we sure GDB will never cause
> some program code to be executed just as result of the user saying
>
>   $ gdb ./program
>
> ?  The above text seems to assume that any such execution at startup
> must be the result of some command-line argument or some configuration
> file, but is that 110% certain, and are we sure this will _never_
> change?

Am I 110% certain?  No.  I'm never going to claim that level of
certainty on a topic.  But I am 99% certain.

Am I sure this will _never change?  No.  But that's OK.

This document is about writing down an agreed project position on this
behaviour today.

If tomorrow someone wants to propose a patch where 'gdb ./prog' would
automatically run './prog' then they are welcome to do so.  But part of
that patch would require updating the SECURITY.txt document, and
hopefully, by touching the SECURITY.txt document, this would trigger a
conversation about whether we actually wanted to make that change.

But that doesn't mean this document cannot be changed.

FYI, right now, if someone did propose such a patch, I would be against
it being merged due to the possible security implications.

>
>>   Any bug in GDB or gdbserver that can trigger arbitrary code
>>   execution without the program being debugged having been executed,
>>   for example, by simply loading the program into GDB or gdbserver, is
>>   considered a security bug.
>
> Similar issue here: when this says "having been executed", does it
> mean executed explicitly by a user command, or does it also mean
> executed as part of the administrivia of loading the program?

I reworded this as:

  Any bug in GDB or gdbserver that can trigger arbitrary code
  execution without the program being debugged having been executed by
  a user command, would be considered a security bug.  For example, if
  simply loading a program into GDB could trigger arbitrary code
  execution, then this would be a security issue.

This is just trying to reinforce the point that _unless_ the user types
'run' (or equivalent) then there should be no arbitrary code execution
as a result of simply loading the program, or inspecting the program.

>
>>   Within this section, mention of GDB should be read as meaning GDB,
>                          ^^^^^^^^^^^^^^
> "references to GDB", not "mention of GDB"
>
>>   In some cases a developer may be given a program from an untrusted
>>   source and be asked to debug an issue.  In this situation we would
>>   say GDB is being used to debug untrusted code.  In this case the
>>   user should take all the precautions when running GDB that they
>>   would normally take when running an untrusted program outside of
>>   GDB, e.g. running within a sandboxed environment.
>
> This text contradicts the remark above that a malicious program could
> change its behavior when running under GDB.
>
>>   When using GDB or to examine an untrusted program (with gdbserver,
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Something is wrong here: some word missing or maybe "or" should be
> deleted.
>
>>   2. It is possible that a malicious executable could trigger a bug in
>>      GDB to perform a malicious action.  Such a bug would be a
>                                            ^^^^^^^^^^^^^^^^^^^^^
> Did you mean "would not be"? otherwise this sentence makes no sense,
> because of what follows starts with "but":
>
>>      security bug, but it would be best practice to guard against such
>>      a bug if possible.

I reworded this paragraph as:

  2. Though every effort is made to ensure GDB is free from bugs, it
     cannot be guaranteed that GDB is bug free.  It might be possible
     that even examining an untrusted program could trigger a bug in
     GDB which, in turn could trigger an unwanted effect on the system
     running GDB.

What I'm trying to say here is that, though you _should_ be free to load
and examine an untrusted binary in GDB, the reality is that GDB is not
hardened against malicious binaries, e.g. using a fuzzing tool to
generate invalid binaries will often trigger buffer overflow issues in
GDB.  Potentially these _might_ be exploitable to trigger arbitrary code
execution.

I feel, as a project we might want to say that it is safe to load an
untrusted binary, in reality, if someone is looking to be 100% secure,
then even inspecting an untrusted binary should be done in a sandboxed
environment.

>
>>   When using GDB and gdbserver to perform remote debug, the connection
>>   between the two components in by design insecure.  It is up to the
>                                ^^
> "is"
>
>>   In order to report a private security bug that is not immediately
>>   public, please contact one of the downstream distributions with
>
> "immediately public"? what's that?
>
>>   The team contacted will take care of details such as vulnerability
>>   rating and CVE assignment (http://cve.mitre.org/about/).  It is likely
>>   that the team will ask to file a public bug because the issue is
>>   sufficiently minor and does not warrant an embargo.  An embargo is not
>>   a requirement for being credited with the discovery of a security
>>   vulnerability.
>
> This doesn't explain what is "embargo".  Should it?  I, for one, don't
> know what that means.

In this context it just means to keep the details private.

I reworked this to remove use of the word "embargo", I actually stole
this bit of text from the binutils SECURITY.txt file, but on re-reading
I feel it would be better written in plainer language, so that's what
I've done.

I'll post a V3 shortly which contains all of my updates.

Thanks,
Andrew