[PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Andrew Burgess <aburgess@redhat.com>]

I believe there is some ambiguity in the SECURITY.txt file when it
comes to bugs within the DWARF and BFD parsing code.

Here are the relevant passages:

  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.

And:

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

And later on:

  There are known bugs in GDB related to loading malformed executables
  and parsing the debug information, a consequence of these bugs is
  that a malicious program could trigger undefined behavior in GDB,
  which could be used to trigger arbitrary code execution.

  ...

  As there are already known bugs in GDB relating to undefined
  behavior triggered from malformed programs, further bugs in this
  area should still be reported, but are unlikely to be given high
  priority.  Bugs in GDB that are triggered by well-formed programs
  should also be reported, and are likely to be treated as higher
  priority as these are more likely to impact normal use of GDB.

I think this final paragraph is confusing.  Is a bug in the DWARF/BFD
parser a security issue or not?

I certainly have no desire to invite a deluge of security bugs
relating the DWARF/BFD parsing, nor am I volunteering to spend all my
time fixing these bugs.

But, given our definition of a security bug, I think we need to
acknowledge that DWARF/BFD parser bugs are security issues (if they
meet the earlier definition).  However, I do think we should be honest
about how likely these issues are to be fixed, i.e. not necessarily as
a high priority.

The changes I propose here then clarify this area:

  1. Clarify that the ideal is we'd like GDB to be bug free, but be
     firmer in saying that we believe there are bugs, and that these
     bugs could be security issues.

  2. Rewording, replace 'when using GDB with an untrusted binary' with
     'when examining or debugging an untrusted binary'.  This avoids
     repeating GDB and places the focus on the actions being performed.

  3. The real change: clearly state that bugs in the DWARF/BFD parser
     can be security bugs, but they are unlikely to be considered high
     priority, and users should instead use sandboxing to provide
     protection.  The text about bugs from well-formed programs is
     retained.
---
 gdb/SECURITY.txt | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/gdb/SECURITY.txt b/gdb/SECURITY.txt
index 63e110055db..533b70b5875 100644
--- a/gdb/SECURITY.txt
+++ b/gdb/SECURITY.txt
@@ -184,26 +184,30 @@ Security Realities Of The GDB Project
 
   When using GDB to examine, but not execute, an untrusted program
   (with gdbserver, the program will be started, but paused at the
-  first instruction and not run further), there should be no security
-  risks, however the GDB maintainers don't currently believe that GDB
-  or gdbserver is reliable enough to ensure that there are no security
-  risks.
+  first instruction and not run further), ideally there should be no
+  security risks.  However, there are known bugs in GDB related to
+  loading malformed executables and parsing the debug information, a
+  consequence of these bugs is that a malicious program could trigger
+  undefined behavior in GDB, which could be used to trigger arbitrary
+  code execution.  This means that even just loading an untrusted
+  executable into GDB, without executing the program, can pose a
+  security risk.
 
-  There are known bugs in GDB related to loading malformed executables
-  and parsing the debug information, a consequence of these bugs is
-  that a malicious program could trigger undefined behavior in GDB,
-  which could be used to trigger arbitrary code execution.
+  Given these risks, the advice of the GDB project is that, when
+  examining or debugging an untrusted binary, always do so in a
+  secure, sandboxed environment.
 
-  Given these risks, the advice of the GDB project is that, when using
-  GDB with an untrusted binary, always do so in a secure, sandboxed
-  environment.
-
-  As there are already known bugs in GDB relating to undefined
-  behavior triggered from malformed programs, further bugs in this
-  area should still be reported, but are unlikely to be given high
-  priority.  Bugs in GDB that are triggered by well-formed programs
-  should also be reported, and are likely to be treated as higher
-  priority as these are more likely to impact normal use of GDB.
+  Bugs related to parsing malformed executables and debug information
+  can meet the definition of a security bug as described in this
+  document.  However, the GDB project believes there are likely to be
+  many such bugs, and addressing all of them as high priority security
+  issues is not feasible given current project resources.  Users
+  should instead rely on sandboxing as the primary mitigation.  Bugs
+  in this area should still be reported through the normal bug
+  reporting process and will be addressed when possible.  Bugs in GDB
+  that are triggered by well-formed programs should also be reported,
+  and are likely to be treated as higher priority as these are more
+  likely to impact normal use of GDB.
 
   When using GDB and gdbserver to perform remote debug, the connection
   between the two components is by design insecure.  It is up to the
-- 
2.25.4