gdb: multiple vulnerabilities [LWN.net]

Package(s):

gdb

CVE #(s):

CAN-2005-1704 CAN-2005-1705

Created:

May 20, 2005

Updated:

August 11, 2006

Description:

Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an integer overflow in the BFD library, resulting in a heap overflow. A review also showed that by default, gdb insecurely sources initialization files from the working directory. Successful exploitation would result in the execution of arbitrary code on loading a specially crafted object file or the execution of arbitrary commands.

Alerts:

Red Hat	RHSA-2006:0354-01	2006-08-10
Red Hat	RHSA-2006:0368-01	2006-07-20
Mandriva	MDKSA-2005:215	2005-11-23
Fedora	FEDORA-2005-1033	2005-10-27
Fedora	FEDORA-2005-1032	2005-10-27
Red Hat	RHSA-2005:801-01	2005-10-18
Red Hat	RHSA-2005:763-01	2005-10-11
Red Hat	RHSA-2005:709-01	2005-10-05
Red Hat	RHSA-2005:673-01	2005-10-05
Red Hat	RHSA-2005:659-01	2005-09-28
Fedora	FEDORA-2005-498	2005-06-29
Fedora	FEDORA-2005-497	2005-06-29
Gentoo	200506-01	2005-06-01
Trustix	TSLSA-2005-0025	2005-05-31
Mandriva	MDKSA-2005:095	2005-05-30
Ubuntu	USN-136-2	2005-05-27
Ubuntu	USN-136-1	2005-05-27
Ubuntu	USN-135-1	2005-05-27
Gentoo	200505-15	2005-05-20

(Log in to post comments)

gdb: multiple vulnerabilities

Posted May 26, 2005 9:18 UTC (Thu) by nix (subscriber, #2304) [Link]

A review also showed that by default, gdb insecurely sources initialization files from the working directory.

I'd hope that this wasn't 'fixed'. Isn't it, like, a feature that rather a lot of people rely on? :)

(Indeed, I see no sign that .gdbinit is sourced from anywhere different now.)

gdb: multiple vulnerabilities

Posted Oct 21, 2005 15:28 UTC (Fri) by smoogen (subscriber, #97) [Link]

Usually insecure sourcing is considered:

Not checking that directory is not world-writable
Not checking that file is not world-writable
Not checking that the file is a sym-link
Blindly executing any commands in the source file.

gdb: multiple vulnerabilities

Posted Nov 3, 2005 5:55 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Just the same, gdb is a special case, and developers may need the ability to set up a complicated environment from a .gdbinit file, and this may include executing fairly arbitrary commands. The file is only read, not written, so there is no special reason to be suspicious of a symbolic link (in fact, it is quite likely that a symbolic link would be used in cases where parallel trees are used to produce code for multiple platforms using separate object trees for each).

gdb users should be assumed to be developers who have a clue about what they are doing.

gdb: multiple vulnerabilities

Posted Nov 3, 2005 14:27 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

Well, suppose I leave a malicious .gdbinit in /tmp and one of your daemons happened to dump core in /tmp. So, you fire up GDB and get p3wned. Not exactly a good state to be in.

It seems like the shared working area and symlink problems could be solved by sourcing a trusted file in the user's home directory, and placing within that file any customizations on the default security policy.