| |||||||||||||
gdb: multiple vulnerabilitiesgdb: multiple vulnerabilitiesPosted Oct 21, 2005 15:28 UTC (Fri) by smoogen (subscriber, #97)In reply to: gdb: multiple vulnerabilities by nix Parent article: gdb: multiple vulnerabilities
Usually insecure sourcing is considered:
Not checking that directory is not world-writable
(Log in to post comments)
gdb: multiple vulnerabilities Posted Nov 3, 2005 5:55 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Just the same, gdb is a special case, and developers may need the ability to set up a complicated environment from a .gdbinit file, and this may include executing fairly arbitrary commands. The file is only read, not written, so there is no special reason to be suspicious of a symbolic link (in fact, it is quite likely that a symbolic link would be used in cases where parallel trees are used to produce code for multiple platforms using separate object trees for each).gdb users should be assumed to be developers who have a clue about what they are doing.
gdb: multiple vulnerabilities Posted Nov 3, 2005 14:27 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Well, suppose I leave a malicious .gdbinit in /tmp and one of your daemons happened to dump core in /tmp. So, you fire up GDB and get p3wned. Not exactly a good state to be in.
It seems like the shared working area and symlink problems could be solved by sourcing a trusted file in the user's home directory, and placing within that file any customizations on the default security policy.
|
|||||||||||||