Bugzilla Bug 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.

Created an attachment (id=55708) [details]
gdb-6.3-gdbinit-stat.patch

something like this is what you looking for?

solar: looks good, should be an improvement, and can still be overridden (to
read other users .gdbinit's) if a user requires by adding 'source .gdbinit' to
~/.gdbinit.

Created an attachment (id=55710) [details]
use existing stat()

save the overhead from another stat, one already exists a little earlier.

Created an attachment (id=55719) [details]
gdb-6.3-gdbinit-stat.patch

adds check to ensure if our .gdbinit file was in pwd it's not world writeable 
either using existing stat.

note I've not tested that yet. will do in a few mins.

Created an attachment (id=55721) [details]
gdb-6.3-gdbinit-stat.patch

ok other patch had an extra ) in it.
How about this one?

anyone chatted with upstream gdb maintainers about this ?

I just filed a bug at
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb
but they have a really lame gnats that did not tell me a bug # or anything.  I 
searched the db right after that to see if i could get a bug # or something but 
nothing.... So I reported it, it went somewhere but I've got no clue where 
it's at now. I don't like dealing with lame things more than one time so heres
a list of maintainers.


                        Global Maintainers
                           (alphabetic)

Jim Blandy                      jimb@redhat.com
Kevin Buettner                  kevinb@redhat.com
Andrew Cagney                   cagney@gnu.org
J.T. Conklin                    jtc@acorntoolworks.com
Fred Fish                       fnf@ninemoons.com
Daniel Jacobowitz               dan@debian.org
Mark Kettenis                   kettenis@gnu.org
Peter Schauer                   Peter.Schauer@regent.e-technik.tu-muenchen.de
Stan Shebs                      shebs@apple.com
Michael Snyder                  msnyder@redhat.com
Elena Zannoni                   ezannoni@redhat.com
Eli Zaretskii                   eliz@gnu.org

Ok cool we just got the bug # assigned.

It has the internal identification `gdb/1908'.
The individual assigned to look at your
report is: unassigned. 

>Category:       gdb
>Responsible:    unassigned
>Synopsis:       potential security problem
>Arrival-Date:   Sat Apr 09 02:28:01 UTC 2005

gdb also reads ./.gdb_history I however have no idea if this can be sec
problem. 

So yeah we want to use this patch for our own gdb-6.x?

solar: I had a look at the history file mechanism, It doesnt save history by
default, but should you enter set  history save, either in gdb or in your
~/.gdbinit it will happily write onto a symlink, so enabling this feature and
starting gdb in an untrusted directory is not a good idea :)

It will read somebody elses .gdb_history, but apart from being able to insert
commands into the history buffer (doesnt seem like a great idea, but no obvious
attack via this vector).

I think we should 'set history filename ~/.gdb_history' in the gdbinit we
distribute with some comments, so that users who enable saving history across
sessions can see this option should be set as well.

solar/taviso any news on this one?

Fixed in .gdbinit handling in gdb-6.3-r2 and left the history alone as not all 
arches have a default /etc/skel/.gdbinit file.

Current Keywords:
gdb-6.0:  alpha -hppa ia64 
gdb-6.0-r1:  
gdb-6.1:  s390 
gdb-6.1.1:  sparc 
gdb-6.2:  ppc 
gdb-6.2.1:  mips 
gdb-6.2.1-r1:  -sparc 
gdb-6.3:  ppc64 hppa amd64 arm x86 
gdb-6.3-r1:  
gdb-6.3-r2:  ~arm ~hppa ~x86 ~amd64 ~ppc ~alpha ~sparc ~ppc64 ~mips

GLSA 200505-15