Re: [RFC] Adding a SECURITY policy for GDB

[Siddhesh Poyarekar <siddhesh@redhat.com>]

On Thu, Nov 16, 2023 at 12:29 PM Paul Koning <paulkoning@comcast.net> wrote:
> > 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.
>

That does not reflect reality though.  Given how bfd, etc. are today,
the idea of gdb being able to securely load untrusted binaries (even
without running them) is a pretty ambitious target IMO.  Basically all
bfd memory safety bugs become *gdb* memory safety bugs and all of the
current fuzzing results then become incredibly relevant as security
issues because then it's just a matter of tricking users into
loading/inspecting arbitrary binaries to compromise their systems.
They're no longer just minor annoyances that distract us from regular
development.

Bubbling up and out a bit, when we state some threat scenario as being
accepted as a security issue in the security policy, we not only
promise users that we'll treat those issues as security issues, we
also make the implicit statement that gdb protects them from that
threat scenario, thus endorsing such use.  This implicit statement has
more serious consequences and based on the current state of bugs, does
not correspond to reality.

The promise of treating such bugs as security issues however is
subjective, i.e. it depends on whether the gdb community considers
that it has the resources to respond to all such bugs as if they were
security issues, i.e. promptly fix them in master, all supported
release branches and then in downstream packages.  Even if this were
fixed with that en vogue holy grail of rewriting things in rust, I
would hesitate to make such a guarantee without sandboxing (e.g. with
a --insecure flag that does the loading and inspection in an isolated
namespace with a limited set of fds), but that's just my personal
opinion.

Thanks,
Sid