| |||||||||||||
gdb: multiple vulnerabilitiesgdb: multiple vulnerabilitiesPosted May 26, 2005 9:18 UTC (Thu) by nix (subscriber, #2304)In reply to: gdb: multiple vulnerabilities by mjc@redhat.com Parent article: gdb: multiple vulnerabilities
A review also showed that by default, gdb insecurely sources initialization files from the working directory.I'd hope that this wasn't 'fixed'. Isn't it, like, a feature that rather a lot of people rely on? :) (Indeed, I see no sign that .gdbinit is sourced from anywhere different now.)
(Log in to post comments)
gdb: multiple vulnerabilities Posted Oct 21, 2005 15:28 UTC (Fri) by smoogen (subscriber, #97) [Link] Usually insecure sourcing is considered:
Not checking that directory is not world-writable
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.
|
|||||||||||||