Re: [RFC] Adding a SECURITY policy for GDB

[Paul Koning <paulkoning@comcast.net>]

> On Nov 16, 2023, at 12:19 PM, Andrew Burgess <aburgess@redhat.com> wrote:
> 
> Simon Marchi <simark@simark.ca> writes:
> 
>>> ...
>> 
>> My opinion would have been that just loading a file in GDB just to
>> inspect it statically should be a safe thing to do, even with a
>> malicious binary.  It's possible to do in theory, by being defensive and
>> very careful of everything we read.
> 
> In an ideal world I'd love to say that just loading a binary for
> inspection is a safe thing to do.  But I think the concern would be,
> could we imagine a situation where a malicious binary could somehow
> trigger GDB to start executing the inferior without any user
> interaction?
> 
> Given the complexity of the DWARF parser, I'm not sure we can't say for
> certain that such a bug couldn't exist.
> 
> And if we accept that such a bug could exist, then it seems like we have
> a choice: we can declare that a user should sandbox GDB before touching
> an untrusted binary, or we can say that any bugs in GDB related to
> simply inspecting a binary that might cause undefined behaviour in GDB,
> could, potentially, cause GDB to execute the inferior unasked, and could
> be considered security issues.

I would lean towards "security issue".  Yes, the paranoid can use sandboxes, but that's a pain in the neck that people would not expect to do for software that by design and intent should not need such precautions.  With GDB, the expectation is that it executes supplied binaries, with all that implies, if and only if you ask it to do so.  There are cases where that happens even if you didn't say "run" (invoking target functions from the command line, for example).  But loading and examining a binary are not expected to cause execution, so a hypothetical bug that does execute bits other than GDB itself in such a case are very much unexpected and deserve to be called a security bug.

	paul