Re: [RFC] Adding a SECURITY policy for GDB

[Simon Marchi <simark@simark.ca>]

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 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.

Simon