gdb/1908: potential security problem

solar@gentoo.org solar@gentoo.org
Sat Apr 9 02:28:00 GMT 2005


>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



More information about the Gdb-prs mailing list