88398 2005-04-08 12:48 0000 sys-devel/gdb: default config, potential security problem? 2005-05-21 02:37:04 0000 1 1 1 Unclassified Gentoo Security Default Configs unspecified All All RESOLVED FIXED P2 normal --- 1 taviso@gentoo.org security@gentoo.org toolchain@gentoo.org taviso@gentoo.org 2005-04-08 12:48:28 0000 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. solar@gentoo.org 2005-04-08 13:29:13 0000 Created an attachment (id=55708) gdb-6.3-gdbinit-stat.patch something like this is what you looking for? taviso@gentoo.org 2005-04-08 13:39:45 0000 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. taviso@gentoo.org 2005-04-08 13:54:26 0000 Created an attachment (id=55710) use existing stat() save the overhead from another stat, one already exists a little earlier. solar@gentoo.org 2005-04-08 15:46:28 0000 Created an attachment (id=55719) 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. solar@gentoo.org 2005-04-08 15:53:02 0000 note I've not tested that yet. will do in a few mins. solar@gentoo.org 2005-04-08 16:13:43 0000 Created an attachment (id=55721) gdb-6.3-gdbinit-stat.patch ok other patch had an extra ) in it. How about this one? vapier@gentoo.org 2005-04-08 16:32:28 0000 anyone chatted with upstream gdb maintainers about this ? solar@gentoo.org 2005-04-08 19:30:54 0000 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 solar@gentoo.org 2005-04-08 19:45:31 0000 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 solar@gentoo.org 2005-04-09 16:55:27 0000 gdb also reads ./.gdb_history I however have no idea if this can be sec problem. solar@gentoo.org 2005-04-09 19:19:06 0000 So yeah we want to use this patch for our own gdb-6.x? taviso@gentoo.org 2005-04-10 01:25:47 0000 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. jaervosz@gentoo.org 2005-04-23 07:39:07 0000 solar/taviso any news on this one? solar@gentoo.org 2005-04-24 13:04:03 0000 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 taviso@gentoo.org 2005-05-21 02:37:04 0000 GLSA 200505-15 55708 2005-04-08 13:29 0000 gdb-6.3-gdbinit-stat.patch gdb-6.3-gdbinit-stat.patch text/plain LS0tIGdkYi9tYWluLmMub3JpZwkyMDA1LTA0LTA4IDE2OjIxOjQzLjAwMDAwMDAwMCAtMDQwMAor KysgZ2RiL21haW4uYwkyMDA1LTA0LTA4IDE2OjI3OjEzLjAwMDAwMDAwMCAtMDQwMApAQCAtMzAs NiArMzAsNyBAQAogCiAjaW5jbHVkZSAiZ2V0b3B0LmgiCiAKKyNpbmNsdWRlIDxzeXMvc3RhdCxo PgogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgogI2luY2x1ZGUgImdkYl9zdGF0LmgiCiAjaW5jbHVk ZSA8Y3R5cGUuaD4KQEAgLTY5NSw3ICs2OTYsMTEgQEAKICAgICAgIHx8IG1lbWNtcCAoKGNoYXIg KikgJmhvbWVidWYsIChjaGFyICopICZjd2RidWYsIHNpemVvZiAoc3RydWN0IHN0YXQpKSkKICAg ICBpZiAoIWluaGliaXRfZ2RiaW5pdCkKICAgICAgIHsKLQljYXRjaF9jb21tYW5kX2Vycm9ycyAo c291cmNlX2NvbW1hbmQsIGdkYmluaXQsIDAsIFJFVFVSTl9NQVNLX0FMTCk7CisJc3RydWN0IHN0 YXQgc3Q7CisJaWYgKChzdGF0KGdkYmluaXQsICZzdCkpICE9ICgtMSkpIHsKKwkgIGlmIChzdC5z dF91aWQgPT0gZ2V0dWlkKCkpCisJICAJY2F0Y2hfY29tbWFuZF9lcnJvcnMgKHNvdXJjZV9jb21t YW5kLCBnZGJpbml0LCAwLCBSRVRVUk5fTUFTS19BTEwpOworCX0KICAgICAgIH0KIAogICBmb3Ig KGkgPSAwOyBpIDwgbmNtZDsgaSsrKQo= 55710 2005-04-08 13:54 0000 use existing stat() gdb-6.3-gdbinit-stat.patch text/plain LS0tIGdkYi02LjMvZ2RiL21haW4uYy5vcmlnCTIwMDQtMDgtMTAgMjM6MzY6MzkuMDAwMDAwMDAw ICswMTAwCisrKyBnZGItNi4zL2dkYi9tYWluLmMJMjAwNS0wNC0wOCAyMTo0NDo1OC4wMDAwMDAw MDAgKzAxMDAKQEAgLTY5Myw3ICs2OTMsNyBAQAogCiAgIGlmICghaG9tZWRpcgogICAgICAgfHwg bWVtY21wICgoY2hhciAqKSAmaG9tZWJ1ZiwgKGNoYXIgKikgJmN3ZGJ1Ziwgc2l6ZW9mIChzdHJ1 Y3Qgc3RhdCkpKQotICAgIGlmICghaW5oaWJpdF9nZGJpbml0KQorICAgIGlmICghaW5oaWJpdF9n ZGJpbml0ICYmIChjd2RidWYuc3RfdWlkID09IGdldHVpZCgpKSkKICAgICAgIHsKIAljYXRjaF9j b21tYW5kX2Vycm9ycyAoc291cmNlX2NvbW1hbmQsIGdkYmluaXQsIDAsIFJFVFVSTl9NQVNLX0FM TCk7CiAgICAgICB9Cg== 55719 2005-04-08 15:46 0000 gdb-6.3-gdbinit-stat.patch gdb-6.3-gdbinit-stat.patch text/plain LS0tIGdkYi9tYWluLmMub3JpZwkyMDA1LTA0LTA4IDE4OjIxOjUwLjAwMDAwMDAwMCAtMDQwMAor KysgZ2RiL21haW4uYwkyMDA1LTA0LTA4IDE4OjQxOjE1LjAwMDAwMDAwMCAtMDQwMApAQCAtNjkz LDcgKzY5Myw3IEBACiAKICAgaWYgKCFob21lZGlyCiAgICAgICB8fCBtZW1jbXAgKChjaGFyICop ICZob21lYnVmLCAoY2hhciAqKSAmY3dkYnVmLCBzaXplb2YgKHN0cnVjdCBzdGF0KSkpCi0gICAg aWYgKCFpbmhpYml0X2dkYmluaXQpCisgICAgaWYgKCFpbmhpYml0X2dkYmluaXQgJiYgKGN3ZGJ1 Zi5zdF91aWQgPT0gZ2V0dWlkKCkpICYmICghY3dkYnVmLnN0X21vZGUgJiAoU19JV09USCkpKSkK ICAgICAgIHsKIAljYXRjaF9jb21tYW5kX2Vycm9ycyAoc291cmNlX2NvbW1hbmQsIGdkYmluaXQs IDAsIFJFVFVSTl9NQVNLX0FMTCk7CiAgICAgICB9Cg== 55721 2005-04-08 16:13 0000 gdb-6.3-gdbinit-stat.patch gdb-6.3-gdbinit-stat.patch text/plain LS0tIGdkYi9tYWluLmMub3JpZwkyMDA1LTA0LTA4IDE4OjIxOjUwLjAwMDAwMDAwMCAtMDQwMAor KysgZ2RiL21haW4uYwkyMDA1LTA0LTA4IDE4OjUwOjU4LjAwMDAwMDAwMCAtMDQwMApAQCAtNjkz LDcgKzY5Myw3IEBACiAKICAgaWYgKCFob21lZGlyCiAgICAgICB8fCBtZW1jbXAgKChjaGFyICop ICZob21lYnVmLCAoY2hhciAqKSAmY3dkYnVmLCBzaXplb2YgKHN0cnVjdCBzdGF0KSkpCi0gICAg aWYgKCFpbmhpYml0X2dkYmluaXQpCisgICAgaWYgKCFpbmhpYml0X2dkYmluaXQgJiYgKGN3ZGJ1 Zi5zdF91aWQgPT0gZ2V0dWlkKCkpICYmICghY3dkYnVmLnN0X21vZGUgJiAoU19JV09USCkpKQog ICAgICAgewogCWNhdGNoX2NvbW1hbmRfZXJyb3JzIChzb3VyY2VfY29tbWFuZCwgZ2RiaW5pdCwg MCwgUkVUVVJOX01BU0tfQUxMKTsKICAgICAgIH0K