Re: [V3] [RFC] Adding a SECURITY policy for GDB

[Andrew Burgess <aburgess@redhat.com>]

Here is a V3 proposal for a SECURITY.txt document.

There is much less change from V2 to V3 than V1 to V2.  This was really
me going through and addressing Eli's feedback.  There are still a
couple of open questions from Eli's feedback, so further updates may be
need in the future, hopefully I can get later revisions out quicker than
V3.

All feedback would be great.

Thanks,
Andrew

--

GNU Debugger Security Policy
============================

Introduction
------------

  The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
  another program.  This can be done by controlling the execution of
  the program being debugged and allowing the user to inspect and
  modify the state of the running program.  Or GDB can be used to
  analyse the program or a core file generated from the program
  without needing to execute the program.

  The program being debugged may be local i.e. on the system on which
  GDB runs or remote, on a different system.

Policy Objectives
-----------------

  The objective of this policy is define what the GDB project
  considers a security bug and what is a non-security bug, and how
  each category of bug should be reported.

  Additionally, this policy will give some general advice to users on
  how to use GDB securely.

Scope Of This Policy
--------------------

  This policy covers all currently supported versions of GDB as
  released from the official GDB website and covers gdb, gdbserver, as
  well as gcore and gdb-add-index, which are packaged with each GDB
  release.  The official GDB website can be found here:

    https://sourceware.org/gdb/

  Remote debugging uses GDB to connect to a remote target.  GDB sends
  commands to the remote target which then controls the process being
  debugged.  The GDB project provides one remote target, gdbserver,
  which is included with official GDB releases.  Bugs within gdbserver
  are in scope for this policy.

  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.  However, any
  bugs in GDB caused by a misbehaving remote target, even when that
  target is not gdbserver, are in scope for this policy.

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.
  Additionally, it is possible for a program to detect when it is run
  under GDB and to change its behavior, so that 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 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 not inside a secure environment are not security bugs in
  gdbserver.

  The connection between GDB and a remote target is not protected by
  either authentication or encryption.  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.

  Any issues that arise due to a failure to protect the connection
  between GDB and a remote target are not security bugs in either GDB
  or gdbserver.

What Is A Security Bug?
-----------------------

  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
  as an arbitrarily different user, or accessing resources
  (e.g. files, sockets, etc) for which the original user would not
  normally have access.

  Any bugs in GDB that result in execution of the program being
  debugged without the user issuing a GDB command triggering execution
  (either from the GDB command line, a GDB configuration file, or from
  the GDB prompt) are considered security bugs.

  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.  Any bug which results in execution of the
  program being debugged without GDB first connecting to the target
  and sending a command that is intended to trigger execution is a
  security bug in gdbserver.

  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.

  The additional tools gcore and gdb-add-index are scripts that wrap
  around GDB.  Any issue in these tools that meet the above
  definitions of a security bug, are considered a security bug.

Security Considerations
-----------------------

  Within this section, references to GDB should be read as meaning
  GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
  otherwise.

  The most common use case for GDB is a developer trying to resolve
  issues within a program that they have either written themselves, or
  within a program that they trust not to be malicious.  In this
  situation we would say GDB is being used to debug trusted code.
  There is no greater security risk from running the program to debug
  through GDB than there is running the program directly.  Additional
  process isolation for the GDB process is only needed if additional
  isolation would have been applied anyway when running the program to
  debug.

  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 secure, sandboxed environment.

  When using GDB to examine an untrusted program (with gdbserver, the
  program can be started, but paused at the first instruction and
  never run further), there should be no security risk, however, there
  are two things to consider:

  1. The risk of inadvertently executing the untrusted program.  It
     would be easy for a user to accidentally issue one of the many
     commands that would start the untrusted program executing.  Even
     the 'start' command, which stops the program being debugged at
     the start of the main function might not be safe, a program can
     embed a malicious payload before the main function is reached.

  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.

  Given these risks, the advice of the GDB project is, when using GDB
  with an untrusted binary, to do so in a secure, sandboxed environment.

  When using GDB and gdbserver to perform remote debug, the connection
  between the two components is by design insecure.  It is up to the
  user to protect this connection, for example, only starting
  gdbserver within a secure network.

Reporting Non-Security Bugs
---------------------------

  NOTE: All bugs reported in the GDB Bugzilla are public.

  Non-security bugs, as well as any security bugs that pose limited
  risk to users should be reported in GDB's bugzilla system.  Bugs
  reported in this way will be public.  The bugzilla system can be
  found here:

    https://sourceware.org/bugzilla/

Reporting Security Bugs
-----------------------

  In order to report a private security bug that is not immediately
  made public, please contact one of the downstream distributions with
  security teams.  The following teams have volunteered to handle such
  bugs:

     Red Hat: secalert@redhat.com
     SUSE:    security@suse.de

  Please report the bug to just one of these teams.  It will be shared
  with other teams as necessary.

  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 keeping details of the
  bug private.