Re: [RFC] Adding a SECURITY policy for GDB

[Eli Zaretskii <eliz@gnu.org>]

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

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

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

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

Thanks.