Bug 204845 - CVE-2006-4146 GDB buffer overflow
CVE-2006-4146 GDB buffer overflow
Status: CLOSED DUPLICATE of bug 203881
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
5
All Linux
low Severity low
: ---
: ---
Assigned To: Elena Zannoni
source=vendorsec,reported=20060815,im...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-31 16:51 EDT by Josh Bressers
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-04 02:18:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2006-08-31 16:51:22 EDT
+++ This bug was initially created as a clone of Bug #204841 +++

Will Drewry of the Google Security Team discovered multiple buffer overflows in
GDB's DWARF handling code.  His advisory is below:

The GNU Debugger (GDB) Multiple Vulnerabilities
-----------------------------------------------

Summary
-------

Multiple vulnerabilities have been discovered in the GNU debugger that allow
for the execution of arbitrary code.


Background
----------

GDB is the GNU Project Debugger. It is described on its project page
[http://www.gnu.org/software/gdb/] as allowing "you to see what is going on
`inside' another program while it executes -- or what another program was doing
at the moment it crashed."

DWARF is a information format standard used to represent debugging information
for a specific binary. While the first version was originally used in ELF, ELF
later moved to STABS. In more recent years, DWARF version 2.0 has been
reintroduced into ELF binaries. More information can be found at
http://dwarf.freestandards.org.


Impact
------

A successful exploit would result in the execution of arbitrary code on the
loading of a specially crafted executable.

This a viable mechanism for an attacker to escape restricted environments by
piggybacking exploit code on seeming harmless files often used for debugging.
In the worst case, this could allow for privilege escalation.


Workaround
----------

Do not use GDB on untrusted files that may have DWARF(2) debugging information,
e.g.  binaries and core files. There is no way to verify if an untrusted file
is safe to debug without investigating the debugging symbols manually.


Discussion
----------

Will Drewry <wad@google.com> of the Google Security Team has found multiple
exploitable vulnerabilities in the DWARF and DWARF2 code. Initially,
Tavis Ormandy <taviso@google.com>, also of the Google Security Team,
discovered a crash condition in GDB related to DWARF2 debugging information.
This discovery led to the further exploration of the condition, and the
discovery of the security implications.

The DWARF specification allows location description blocks containing a list of
operations to be used to determine the final real address for some debugging
symbol. GDB evaluates these operations on an unchecked stack buffer of size 64.
This allows for any location block (DW_FORM_block) with more than 64 operations
to overwrite the current stack frame with arbitrary user-supplied data.  This
behavior occurs in both dwarfread.c and dwarfread2.c.


Patch
-----

The following patch will work as a quick fix to the problem:

==== begin patch ====
diff -Naur gdb-6.5.orig/gdb/dwarf2read.c gdb-6.5/gdb/dwarf2read.c
--- gdb-6.5.orig/gdb/dwarf2read.c       2006-05-13 16:46:38.000000000 +0100
+++ gdb-6.5/gdb/dwarf2read.c    2006-08-14 21:37:33.000000000 +0100
@@ -8855,6 +8855,17 @@
                     dwarf_stack_op_name (op));
          return (stack[stacki]);
        }
+
+      /* Enforce maximum stack depth of 63 to avoid ++stacki writing
+         outside of the given size. Also enforce minimum > 0.
+         -- wad@google.com 14 Aug 2006 */
+      if (stacki >= sizeof(stack)/sizeof(*stack) - 1)
+        internal_error (__FILE__, __LINE__,
+                        _("location description stack too deep: %d"),
+                        stacki);
+      if (stacki <= 0)
+        internal_error (__FILE__, __LINE__,
+                        _("location description stack too shallow"));
     }
   return (stack[stacki]);
 }
diff -Naur gdb-6.5.orig/gdb/dwarfread.c gdb-6.5/gdb/dwarfread.c
--- gdb-6.5.orig/gdb/dwarfread.c        2005-12-17 22:33:59.000000000 +0000
+++ gdb-6.5/gdb/dwarfread.c     2006-08-14 21:37:30.000000000 +0100
@@ -2224,6 +2224,17 @@
          stacki--;
          break;
        }
+
+      /* Enforce maximum stack depth of 63 to avoid ++stacki writing
+         outside of the given size. Also enforce minimum > 0.
+         -- wad@google.com 14 Aug 2006 */
+      if (stacki >= sizeof(stack)/sizeof(*stack) - 1)
+        internal_error (__FILE__, __LINE__,
+                        _("location description stack too deep: %d"),
+                        stacki);
+      if (stacki <= 0)
+        internal_error (__FILE__, __LINE__,
+                        _("location description stack too shallow"));
     }
   return (stack[stacki]);
 }
==== end patch ====
Comment 1 Alexandre Oliva 2006-09-04 02:18:10 EDT

*** This bug has been marked as a duplicate of 203881 ***
Comment 2 Kees Cook 2006-09-28 16:35:12 EDT
"stacki <= 0" needs to be changed to "stacki < 0", since stacki==0 is a valid state.
Comment 3 Matthew Miller 2006-10-23 08:49:22 EDT
Can bug #203881 be un-protected now? Thanks.
Comment 4 Josh Bressers 2006-10-23 09:19:44 EDT
No, bug 203881 has no useful public information in it, it will remain a private
bug.  This bug was created to move the relevant public information from that bug
to this one.
Comment 5 Matthew Miller 2006-10-23 09:29:13 EDT
In which case this really shouldn't be marked as a duplicate, should it?

Thanks for clarifying. It's frustrating to run against protected bugs when
investigating issues. I understand that many have to remain that way, but
sometimes they seem to get protected and left so beyond the time when secrecy is
useful, leading to mysterious dead ends when I'm trying to figure out relevant
open issues for Fedora Legacy.
Comment 6 Will Drewry 2006-12-11 12:01:51 EST
(In reply to comment #2)
> "stacki <= 0" needs to be changed to "stacki < 0", since stacki==0 is a valid
state.

I posted this replacement for the patch in the original advisory to a different
bug #:
  
  https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135360

It's been a while since the advisory, but I believe that 0 isn't valid because
the stack should start at > 0 and movement "above" that point in the stack is
invalid.


Note You need to log in before you can comment on or make changes to this bug.