gdb/SECURITY.txt

   1 GNU Debugger Security Policy
   2 ============================
   3
   4 Introduction
   5 ------------
   6
   7   The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
   8   another program.  This can be done by controlling the execution of
   9   the program being debugged and allowing the user to inspect and
  10   modify the state of the running program.  Or GDB can be used to
  11   analyse the program or a core file generated from the program
  12   without needing to execute the program.
  13
  14   The program being debugged may be local i.e. on the system on which
  15   GDB runs or remote, on a different system.
  16
  17 Policy Objectives
  18 -----------------
  19
  20   The objective of this policy is define what the GDB project
  21   considers a security bug and what is a non-security bug, and how
  22   bugs can be reported.
  23
  24   Additionally this policy discusses areas of GDB in which there are
  25   known bugs, how these might lead to security issues, and how this
  26   risk can be mitigated.
  27
  28 Scope Of This Policy
  29 --------------------
  30
  31   This policy covers all currently supported versions of GDB as
  32   released from the official GDB website and covers gdb, gdbserver, as
  33   well as gcore and gdb-add-index, which are packaged with each GDB
  34   release.  The official GDB website can be found here:
  35
  36     https://sourceware.org/gdb/
  37
  38   Remote debugging uses GDB to connect to a remote target.  GDB sends
  39   commands to the remote target which then controls the process being
  40   debugged.  The GDB project provides one remote target, gdbserver,
  41   which is included with official GDB releases.  Bugs within gdbserver
  42   are in scope for this policy.
  43
  44   Other projects also implement remote targets to which GDB can
  45   connect.  Any bugs in these remote targets are out of scope for this
  46   policy and should be reported to the relevant project.  However, any
  47   bugs in GDB caused by a misbehaving remote target, even when that
  48   target is not gdbserver, are in scope for this policy.
  49
  50 What Is A Security Bug?
  51 -----------------------
  52
  53   Any bugs in GDB or gdbserver that result in an unexpected crossing
  54   of a privilege boundary are considered security bugs.  Some examples
  55   of crossing a privilege boundary include: being able to execute code
  56   as an arbitrarily different user, or accessing resources
  57   (e.g. files, sockets, etc) for which the original user would not
  58   normally have access.
  59
  60   Any bugs in GDB that result in execution of the program being
  61   debugged without the user issuing a GDB command triggering execution
  62   (either from the GDB command line, a GDB configuration file, or from
  63   the GDB prompt) are considered security bugs.
  64
  65   GDB will check for and load multiple configuration files.  When
  66   initially started GDB can load user- and system-specific
  67   configuration files, this is done unconditionally as it is assumed
  68   these files are under control of the user and are always safe to
  69   load.
  70
  71   GDB can also load per-project and per-program configuration files,
  72   this is done when a program to debug is loaded into GDB.  These
  73   configuration files will only be loaded if the user has given GDB
  74   permission to load these files.  Any bug in GDB which allows
  75   per-project or per-program configuration files to be loaded without
  76   permission having been granted by the user is considered a security
  77   bug.
  78
  79   When gdbserver is started, if it is passed a program on its command
  80   line then that program will be started, but paused before executing
  81   its first instruction.
  82
  83   Any bug in gdbserver which results in further execution of the
  84   program being debugged without GDB first connecting to the target
  85   and sending a command that is intended to trigger execution is a
  86   security bug in gdbserver.
  87
  88   Any bug in GDB or gdbserver that can trigger arbitrary code
  89   execution without the program being debugged having been executed by
  90   a user command, is considered a security bug, e.g. if loading a
  91   program into GDB could trigger arbitrary code execution, then this
  92   is a security issue.
  93
  94   The additional tools gcore and gdb-add-index are scripts that wrap
  95   around GDB.  Any issue in these tools that meet the above
  96   definitions of a security bug, are considered a security bug.
  97
  98 What Is Not A Security Bug
  99 --------------------------
 100
 101   In the context of local debugging, when GDB is used to execute a
 102   program, the program runs with the same privileges as GDB itself.
 103
 104   Any issues that arise from running an untrusted program outside of a
 105   secure environment are not security bugs in GDB.  Any issues that
 106   arise from running an untrusted program through GDB inside a secure
 107   environment are only security bugs if GDB is required in order to
 108   trigger the issue.
 109
 110   It is possible for a program to detect when it is run under GDB and
 111   to change its behavior so that unwanted behavior may only appear
 112   when a program is run under GDB.  Any issues that arise due to an
 113   untrusted program detecting GDB and changing its behaviour are not
 114   security issues in GDB unless the issue also meet some other
 115   definition of a security bug.
 116
 117   In the context of remote debugging, the program being debugged is
 118   run with the same privileges as gdbserver.  As with GDB in the local
 119   debugging case, any issues that arise from running an untrusted
 120   program outside of a secure environment are not security bugs in
 121   gdbserver.
 122
 123   The connection between GDB and a remote target is not protected by
 124   either authentication or encryption.  Connecting to a remote target
 125   allows for arbitrary code execution on the remote system with the
 126   same privileges as the remote user, and any resource that the remote
 127   user can access can be read by GDB, and downloaded to the local
 128   machine on which GDB is running.  As such, users need to take
 129   independent measures to secure the connection between GDB and the
 130   remote target.
 131
 132   Any issues that arise due to a failure to protect the connection
 133   between GDB and a remote target are not security bugs in either GDB
 134   or gdbserver.
 135
 136 Security Realities Of The GDB Project
 137 -------------------------------------
 138
 139   Within this section, references to GDB should be read as meaning
 140   GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
 141   otherwise.
 142
 143   The most common use case for GDB is a developer trying to resolve
 144   issues within a program that they have either written themselves, or
 145   within a program that they trust not to be malicious.  In this
 146   situation we would say GDB is being used to debug trusted code.
 147   There is no greater security risk from running the program to debug
 148   through GDB than there is running the program directly.  Additional
 149   process isolation for the GDB process is only needed if additional
 150   isolation would have been applied anyway when running the program to
 151   debug.
 152
 153   In some cases a developer may be given a program from an untrusted
 154   source and be asked to debug an issue.  In this situation we would
 155   say GDB is being used to debug untrusted code.  In this case the
 156   user should take all the precautions when running GDB that they
 157   would normally take when running an untrusted program outside of
 158   GDB, e.g. running within a secure, sandboxed environment.
 159
 160   When using GDB to examine, but not execute, an untrusted program
 161   (with gdbserver, the program will be started, but paused at the
 162   first instruction and not run further), there should be no security
 163   risks, however the GDB maintainers don't currently believe that GDB
 164   or gdbserver is reliable enough to ensure that there are no security
 165   risks.
 166
 167   There are known bugs in GDB related to loading malformed executables
 168   and parsing the debug information, a consequence of these bugs is
 169   that a malicious program could trigger undefined behaviour in GDB,
 170   which could be used to trigger arbitrary code execution.
 171
 172   Given these risks, the advice of the GDB project is that, when using
 173   GDB with an untrusted binary, always do so in a secure, sandboxed
 174   environment.
 175
 176   As there are already known bugs in GDB relating to undefined
 177   behaviour triggered from malformed programs, further bugs in this
 178   area should still be reported, but are unlikely to be given high
 179   priority.  Bugs in GDB that are triggered by well-formed programs
 180   should also be reported, and are likely to be treated as higher
 181   priority as these are more likely to impact normal use of GDB.
 182
 183   When using GDB and gdbserver to perform remote debug, the connection
 184   between the two components is by design insecure.  It is up to the
 185   user to protect this connection, for example, by only starting
 186   gdbserver within a secure network.
 187
 188 Reporting Non-Security Bugs
 189 ---------------------------
 190
 191   NOTE: All bugs reported in the GDB Bugzilla are public.
 192
 193   Non-security bugs, as well as any security bugs that pose limited
 194   risk to users should be reported in GDB's bugzilla system.  Bugs
 195   reported in this way will be public.  The bugzilla system can be
 196   found here:
 197
 198     https://sourceware.org/bugzilla/
 199
 200 Reporting Security Bugs
 201 -----------------------
 202
 203   In order to report a private security bug that is not immediately
 204   made public, please contact one of the downstream distributions with
 205   security teams.  The following teams have volunteered to handle such
 206   bugs:
 207
 208      Red Hat: secalert@redhat.com
 209      SUSE:    security@suse.de
 210
 211   Please report the bug to just one of these teams.  It will be shared
 212   with other teams as necessary.
 213
 214   The team contacted will take care of details such as vulnerability
 215   rating and CVE assignment (http://cve.mitre.org/about/).  It is
 216   likely that the team will ask to file a public bug because the issue
 217   is sufficiently minor and does not warrant keeping details of the
 218   bug private.