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.
$ printf "set args 0wned\nexec /bin/echo\nr\n" > /tmp/.gdbinit
$ cd /tmp
Using host libthread_db library "/lib/libthread_db.so.1".
Program exited normally.
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]
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]
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]
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.
Jim Blandy firstname.lastname@example.org
Kevin Buettner email@example.com
Andrew Cagney firstname.lastname@example.org
J.T. Conklin email@example.com
Fred Fish firstname.lastname@example.org
Daniel Jacobowitz email@example.com
Mark Kettenis firstname.lastname@example.org
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Stan Shebs email@example.com
Michael Snyder firstname.lastname@example.org
Elena Zannoni email@example.com
Eli Zaretskii firstname.lastname@example.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.
>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.
gdb-6.0: alpha -hppa ia64
gdb-6.3: ppc64 hppa amd64 arm x86
gdb-6.3-r2: ~arm ~hppa ~x86 ~amd64 ~ppc ~alpha ~sparc ~ppc64 ~mips