Re: [RFC] Adding a SECURITY policy for GDB

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simark@simark.ca> writes:

> On 11/6/23 08:26, Andrew Burgess wrote:
>>   In the context of local debugging, any bugs in GDB that result in
>>   crossing of a privilege boundary are considered security bugs.  Some
>>   examples of crossing a privilege boundary include; being able to
>>   execute code as an arbitrarily different user, or accessing resources
>>   (e.g. files, sockets, etc) for which the original user would not
>>   normally have access.
>
> Do you have examples of this?  It seems like any bug in that category would
> be bugs in the platform / OS, not GDB.  If such a bug is possible to exploit
> with GDB, the user could another program to exploit the same bug.
>
>>   In the context of remote debugging, there are two components of
>>   relevance; GDB running on the local machine, and a remote target
>>   running as a potentially different user, with different permissions,
>>   on a remote machine.
>> 
>>   The GNU GDB project provides one remote target, gdbserver.  As with
>>   GDB, any bugs in gdbserver that result in crossing of a privilege
>>   boundary are considered security bugs.
>> 
>>   Other projects also implement remote targets to which GDB can
>>   connect.  Any bugs in these remote targets are out of scope for the
>>   GNU GDB project, and should be reported to the relevant project.
>> 
>>   The connection between GDB and a remote target is not protected by
>>   either authentication, or encryption.  Connecting to a remote target
>>   allows for arbitrary code execution on the remote system with the
>>   same privileges as the remote user, and any resource that the remote
>>   user can access can be read by GDB, and downloaded to the local
>>   machine on which GDB is running.  As such users need to take
>>   independent measures to secure the connection between GDB and the
>>   remote target.
>> 
>>   While GDB is intended to be robust against untrusted binaries, it is
>>   not responsible for arbitrary code execution on a system.  As a
>>   result, any bugs exposed by untrusted binaries will be accepted and
>>   treated with appropriate urgency, but will not be considered
>>   security issues.  This applies to local as well as remote debugging;
>>   any bugs in gdbserver, exposed by untrusted binaries will be
>>   accepted and treated with appropriate urgency, but will not be
>>   considered security issues.
>
> 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.

> In practice, I understand that it might not be a realistic goal, given
> the complexity and the current state of BFD / GDB.  And since most of
> the CVEs you got (IIUC) were of this kind, that wouldn't help you much.
> So, I'm fine with that you have, given that I'm not the one who has to
> deal with these annoyances.

Indeed.  Most of the CVEs we're seeing are simply invalid DWARF bugs.
We've never even seen anyone make an attempt to convert the inevitable
GDB crash into an attack.  My concern is that, I don't think I can
credibly say: "Invalid DWARF crashes are not security bugs unless you
can show an actual attack."  So instead I fall back to a default
position of just, "GDB might have bugs.  Don't touch an untrusted binary
unless you're in a sandbox."

Maybe one day we could harden the DWARF parser enough that we can take
the position that reading any binary will be harmless ... but I'm not
sure that's a priority for anyone right now.

This reply has taken me so long to write because I'm aware that the
above sounds like a bit of a cop-out.  I'd be interested to hear
people's thoughts.

Thanks,
Andrew