|Summary:||sys-devel/gdb: default config, potential security problem?|
|Product:||Gentoo Security||Reporter:||Tavis Ormandy (RETIRED) <taviso>|
|Component:||Default Configs||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
use existing stat()
Description Tavis Ormandy (RETIRED) 2005-04-08 12:48:28 UTC
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.
Comment 1 solar (RETIRED) 2005-04-08 13:29:13 UTC
Created attachment 55708 [details, diff] gdb-6.3-gdbinit-stat.patch something like this is what you looking for?
Comment 2 Tavis Ormandy (RETIRED) 2005-04-08 13:39:45 UTC
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.
Comment 3 Tavis Ormandy (RETIRED) 2005-04-08 13:54:26 UTC
Created attachment 55710 [details, diff] use existing stat() save the overhead from another stat, one already exists a little earlier.
Comment 4 solar (RETIRED) 2005-04-08 15:46:28 UTC
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.
Comment 5 solar (RETIRED) 2005-04-08 15:53:02 UTC
note I've not tested that yet. will do in a few mins.
Comment 6 solar (RETIRED) 2005-04-08 16:13:43 UTC
Created attachment 55721 [details, diff] gdb-6.3-gdbinit-stat.patch ok other patch had an extra ) in it. How about this one?
Comment 7 SpanKY 2005-04-08 16:32:28 UTC
anyone chatted with upstream gdb maintainers about this ?
Comment 8 solar (RETIRED) 2005-04-08 19:30:54 UTC
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 email@example.com Kevin Buettner firstname.lastname@example.org Andrew Cagney email@example.com J.T. Conklin firstname.lastname@example.org Fred Fish email@example.com Daniel Jacobowitz firstname.lastname@example.org Mark Kettenis email@example.com Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de Stan Shebs firstname.lastname@example.org Michael Snyder email@example.com Elena Zannoni firstname.lastname@example.org Eli Zaretskii email@example.com
Comment 9 solar (RETIRED) 2005-04-08 19:45:31 UTC
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
Comment 10 solar (RETIRED) 2005-04-09 16:55:27 UTC
gdb also reads ./.gdb_history I however have no idea if this can be sec problem.
Comment 11 solar (RETIRED) 2005-04-09 19:19:06 UTC
So yeah we want to use this patch for our own gdb-6.x?
Comment 12 Tavis Ormandy (RETIRED) 2005-04-10 01:25:47 UTC
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.
Comment 13 Sune Kloppenborg Jeppesen (RETIRED) 2005-04-23 07:39:07 UTC
solar/taviso any news on this one?
Comment 14 solar (RETIRED) 2005-04-24 13:04:03 UTC
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
Comment 15 Tavis Ormandy (RETIRED) 2005-05-21 02:37:04 UTC