This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/1908: potential security problem
- From: solar at gentoo dot org
- To: gdb-gnats at sources dot redhat dot com
- Date: 9 Apr 2005 02:19:42 -0000
- Subject: gdb/1908: potential security problem
- Reply-to: solar at gentoo dot org
>Number: 1908
>Category: gdb
>Synopsis: potential security problem
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Sat Apr 09 02:28:01 UTC 2005
>Closed-Date:
>Last-Modified:
>Originator: http://bugs.gentoo.org/show_bug.cgi?id=88398
>Release: <=gdb-6.3
>Organization:
>Environment:
gdb any
>Description:
A Gentoo's developer Tavis Ormandy <taviso@gentoo.org> reported the following in our bugzilla today
http://bugs.gentoo.org/show_bug.cgi?id=88398
------------------------------------------------------------
by default gdb reads .gdbinit from the current working directory, which obviously can contain commands to execute arbitrary commands. A useful feature, but it isnt hard to imagine a method of social engineering an administrator in to compromising his account, eg
user: "help! when i run lynx in /foo it dumps core, please check it out."
admin helpfully runs gdb in /foo and user has silently taken over his account.
or perhaps compromise a colleagues account if they share access to cvs repository, etc, etc.
example:
$ printf "set args 0wned\nexec /bin/echo\nr\n" > /tmp/.gdbinit
$ cd /tmp
$ gdb
...
Using host libthread_db library "/lib/libthread_db.so.1".
0wned
Program exited normally.
(gdb)
I think we should only allow ~/.gdbinit, if the user wants the feature they can simply add "source .gdbinit", perhaps this can be added with some comments explaining the situation to the example gdbinit we distribute.
a few things other things that might improve this if other disagree:
* confirm current user owns the .gdbinit file.
* print lots of warnings that gdb should only be started in trusted directories.
------------------------------------------------------------
I confirmed the behavior with gdb-6.3
>How-To-Repeat:
>Fix:
I'm am attaching a patch which appears to work around the obvious problem at hand.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-patch; name="gdb-6.3-gdbinit-stat.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gdb-6.3-gdbinit-stat.patch"
LS0tIGdkYi9tYWluLmMub3JpZwkyMDA1LTA0LTA4IDE4OjIxOjUwLjAwMDAwMDAwMCAtMDQwMAor
KysgZ2RiL21haW4uYwkyMDA1LTA0LTA4IDE4OjUwOjU4LjAwMDAwMDAwMCAtMDQwMApAQCAtNjkz
LDcgKzY5Myw3IEBACiAKICAgaWYgKCFob21lZGlyCiAgICAgICB8fCBtZW1jbXAgKChjaGFyICop
ICZob21lYnVmLCAoY2hhciAqKSAmY3dkYnVmLCBzaXplb2YgKHN0cnVjdCBzdGF0KSkpCi0gICAg
aWYgKCFpbmhpYml0X2dkYmluaXQpCisgICAgaWYgKCFpbmhpYml0X2dkYmluaXQgJiYgKGN3ZGJ1
Zi5zdF91aWQgPT0gZ2V0dWlkKCkpICYmICghY3dkYnVmLnN0X21vZGUgJiAoU19JV09USCkpKQog
ICAgICAgewogCWNhdGNoX2NvbW1hbmRfZXJyb3JzIChzb3VyY2VfY29tbWFuZCwgZ2RiaW5pdCwg
MCwgUkVUVVJOX01BU0tfQUxMKTsKICAgICAgIH0K