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 attachment 55708 [details, diff] 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 attachment 55710 [details, diff] use existing stat() save the overhead from another stat, one already exists a little earlier.
Created attachment 55719 [details, diff] 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 attachment 55721 [details, diff] 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
