On Wed, May 25, 2005 at 03:29:09PM +0200, Moritz Muehlenhoff wrote: > Package: gdb > Version: 5.3.20030824-1.1.200309101352 > Severity: important > Tags: security patch > > [I don't think this is RC by itself, but it would be nice if it could be fixed > along with 309677]
Eh, that's an unrelated bug report. I assume you mean 308624. I have no intention of fixing either for woody at this late date; these are security bugs only by a real stretch of imagination. > gdb loads .gdbinit from the current working directory, so it might be possible > to trick someone into using gdb in a specific directory, which contains a > crafted .gdbinit that executes arbitrary commands. > > For full details please see > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1908 > > It contains attached patch. ... which is flat-out wrong. Let's look at it for a moment: > if (!homedir > || memcmp ((char *) &homebuf, (char *) &cwdbuf, sizeof (struct stat))) > - if (!inhibit_gdbinit) > + if (!inhibit_gdbinit && (cwdbuf.st_uid == getuid()) && (!cwdbuf.st_mode > & (S_IWOTH))) > { > catch_command_errors (source_command, gdbinit, 0, RETURN_MASK_ALL); > } Among the problems: - There's a path to this code in which cwdbuf is uninitialized. It requires $HOME to be unset in the environment. - It is vulnerable to a classic symlink race. The file is stat'd and then opened and read from without any further checking. I'll put together a more reliable patch. Running GDB in an untrusted directory, on an untrusted binary, is still not a great idea. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
