* [RFC] Adding a SECURITY policy for GDB
@ 2023-11-06 13:26 Andrew Burgess
2023-11-06 18:55 ` Kevin Buettner
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Andrew Burgess @ 2023-11-06 13:26 UTC (permalink / raw)
To: gdb-patches; +Cc: Siddhesh Poyarekar
Hello!
I'd like to add a SECURITY policy document to the GDB project.
The purpose of this policy would be to define what we, the upstream GDB
project, consider to be a security issue (within GDB) in contrast to
what is just a non-security bug within GDB.
At Red Hat we see a consistent stream of CVEs filled against GDB. When
we discuss these issues internally, we have, at least recently, been of
the opinion that these issues are not really security bugs, but are
just standard, non-security bugs.
Now, that doesn't mean that a non-security bug shouldn't be fixed. But
having issues labelled as CVE often leads to pressure for an immediate
resolution, and often the effort spent fixing a crash within e.g. the
DWARF reader triggered by an invalid ELF, would be better spent fixing
other bugs in GDB.
So, the purpose of this email is to start a discussion about how
the upstream GDB project feels about security vs non-security issues.
If we can reach agreement, and establish an upstream GDB SECURITY
policy, then this might allow downstream distributors of GDB to push
back against CVEs based on the upstream policy document.
It is worth noting that binutils has already adopted a SECURITY policy,
which can be found in binutils-gdb/binutils/SECURITY.txt.
There is also binutils-gdb/SECURITY.txt, which does refer readers to
binutils-gdb/gdb/SECURITY.txt, even though this file does not yet exist!
Below is my straw-man proposal for a SECURITY.txt document. Given the
position I've outlined above, this document does try to make it clear
that pretty much no bugs in GDB should be considered a security issue.
I'd be interested to hear:
* Do people feel I'm being too restrictive in what I consider a
security issue? Are there any additional classes of bug that you
would see as a security issue within GDB?
* I've tried to highlight areas of GDB that might pose a risk if run
in a non-secure setting, e.g. GDB run the inferior, so using GDB to
debug unknown inferiors can allow arbitrary code execution, or that
gdbserver on an open network would allow access to the machine
running gdbserver. Are there any other areas of GDB for which we
should list as being potentially dangerous if not run in a secure
(sandboxed) environment?
Thanks,
Andrew
---
GDB Security Process
====================
What is a GDB security bug?
===========================
A security bug is one that threatens the security of a system or
network, or might compromise the security of data stored on it. The
primary use case of GNU GDB is to diagnose issues in programs.
These programs may be local, i.e. on the system on which GDB runs or
remote, on a different system.
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.
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.
GDB assumes that the remote target is trusted. While GDB is
intended to be robust against incorrectly behaving remote targets, a
malicious remote target could trigger bugs within GDB. Any bugs
exposed by connecting to an untrusted remote target will be accepted
and treated with appropriate urgency, but will not be considered
security issues unless the bug triggers a privilege boundary
crossing.
Reporting private security bugs
===============================
NOTE: All bugs reported in the GDB Bugzilla are public.
In order to report a private security bug that is not immediately
public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle
such bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is likely
that the team will ask to file a public bug because the issue is
sufficiently minor and does not warrant an embargo. An embargo is not
a requirement for being credited with the discovery of a security
vulnerability.
Reporting public security bugs
==============================
It is expected that critical security bugs will be rare, and that most
security bugs can be reported in GDB Bugzilla system, thus making
them public immediately. The system can be found here:
https://sourceware.org/bugzilla/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 13:26 [RFC] Adding a SECURITY policy for GDB Andrew Burgess
@ 2023-11-06 18:55 ` Kevin Buettner
2023-11-06 19:34 ` Simon Marchi
2023-12-08 15:05 ` Andrew Burgess
2 siblings, 0 replies; 31+ messages in thread
From: Kevin Buettner @ 2023-11-06 18:55 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches, Siddhesh Poyarekar
On Mon, 06 Nov 2023 13:26:27 +0000
Andrew Burgess <aburgess@redhat.com> wrote:
> I'd be interested to hear:
>
> * Do people feel I'm being too restrictive in what I consider a
> security issue? Are there any additional classes of bug that you
> would see as a security issue within GDB?
>
> * I've tried to highlight areas of GDB that might pose a risk if run
> in a non-secure setting, e.g. GDB run the inferior, so using GDB to
> debug unknown inferiors can allow arbitrary code execution, or that
> gdbserver on an open network would allow access to the machine
> running gdbserver. Are there any other areas of GDB for which we
> should list as being potentially dangerous if not run in a secure
> (sandboxed) environment?
Some crash detection/analysis tools use GDB in an automatic fashion to
provide diagnostics. I think it should be made clear that such tools
should use GDB in a sandboxed environment.
Kevin
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 13:26 [RFC] Adding a SECURITY policy for GDB Andrew Burgess
2023-11-06 18:55 ` Kevin Buettner
@ 2023-11-06 19:34 ` Simon Marchi
2023-11-06 20:09 ` Siddhesh Poyarekar
` (2 more replies)
2023-12-08 15:05 ` Andrew Burgess
2 siblings, 3 replies; 31+ messages in thread
From: Simon Marchi @ 2023-11-06 19:34 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches; +Cc: Siddhesh Poyarekar
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 19:34 ` Simon Marchi
@ 2023-11-06 20:09 ` Siddhesh Poyarekar
2023-11-06 20:15 ` Simon Marchi
2023-11-09 14:35 ` Willgerodt, Felix
2023-11-16 17:19 ` Andrew Burgess
2 siblings, 1 reply; 31+ messages in thread
From: Siddhesh Poyarekar @ 2023-11-06 20:09 UTC (permalink / raw)
To: Simon Marchi, Andrew Burgess, gdb-patches
On 2023-11-06 14:34, Simon Marchi wrote:
> 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 bu
That's basically boilerplate to state that *if* such a thing ever
happens, it will be considered a security issue. I don't think there
are any such opportunities for misuse in gdb at the moment, but never
say never :)
Thanks,
Sid
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 20:09 ` Siddhesh Poyarekar
@ 2023-11-06 20:15 ` Simon Marchi
2023-11-07 12:17 ` Siddhesh Poyarekar
0 siblings, 1 reply; 31+ messages in thread
From: Simon Marchi @ 2023-11-06 20:15 UTC (permalink / raw)
To: Siddhesh Poyarekar, Andrew Burgess, gdb-patches
On 11/6/23 15:09, Siddhesh Poyarekar wrote:
> On 2023-11-06 14:34, Simon Marchi wrote:
>> 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 bu
>
> That's basically boilerplate to state that *if* such a thing ever happens, it will be considered a security issue. I don't think there are any such opportunities for misuse in gdb at the moment, but never say never :)
Ok... it seems strange because it looks like it invites people to report
as GDB bugs what are bugs in other components (e.g. the kernel). An
option would be to say that exploiting GDB to cross a privilege boundary
is considered a bug of the platform, and not a GDB bug. That would be
even less work for us, and technically accurate, AFAIK.
Simon
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 20:15 ` Simon Marchi
@ 2023-11-07 12:17 ` Siddhesh Poyarekar
2023-11-07 14:22 ` Simon Marchi
0 siblings, 1 reply; 31+ messages in thread
From: Siddhesh Poyarekar @ 2023-11-07 12:17 UTC (permalink / raw)
To: Simon Marchi, Andrew Burgess, gdb-patches
On 2023-11-06 15:15, Simon Marchi wrote:
> On 11/6/23 15:09, Siddhesh Poyarekar wrote:
>> On 2023-11-06 14:34, Simon Marchi wrote:
>>> 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 bu
>>
>> That's basically boilerplate to state that *if* such a thing ever happens, it will be considered a security issue. I don't think there are any such opportunities for misuse in gdb at the moment, but never say never :)
>
> Ok... it seems strange because it looks like it invites people to report
> as GDB bugs what are bugs in other components (e.g. the kernel). An
> option would be to say that exploiting GDB to cross a privilege boundary
> is considered a bug of the platform, and not a GDB bug. That would be
> even less work for us, and technically accurate, AFAIK.
An example of such a CVE could be failure to respect umask[1]. I'm not
sure how one would word that without risking OS bugs being reported
against GDB. I'm inclined to think that it's not as much of a problem
at the moment since we haven't historically gotten any reports in this
area. Maybe if we start getting reports in this area we could tighten
up this text?
Thanks,
Sid
[1] https://blog.rust-lang.org/2023/08/03/cve-2023-38497.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-07 12:17 ` Siddhesh Poyarekar
@ 2023-11-07 14:22 ` Simon Marchi
0 siblings, 0 replies; 31+ messages in thread
From: Simon Marchi @ 2023-11-07 14:22 UTC (permalink / raw)
To: Siddhesh Poyarekar, Andrew Burgess, gdb-patches
On 11/7/23 07:17, Siddhesh Poyarekar wrote:
> An example of such a CVE could be failure to respect umask[1]. I'm not sure how one would word that without risking OS bugs being reported against GDB. I'm inclined to think that it's not as much of a problem at the moment since we haven't historically gotten any reports in this area. Maybe if we start getting reports in this area we could tighten up this text?
>
> Thanks,
> Sid
>
> [1] https://blog.rust-lang.org/2023/08/03/cve-2023-38497.html
>
Ah ok, with that example it makes sense. I was only thinking in terms
of the user of GDB being the bad person, accessing someone else's data.
Not someone else accessing the GDB user's data.
Simon
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [RFC] Adding a SECURITY policy for GDB
2023-11-06 19:34 ` Simon Marchi
2023-11-06 20:09 ` Siddhesh Poyarekar
@ 2023-11-09 14:35 ` Willgerodt, Felix
2023-11-16 17:19 ` Andrew Burgess
2 siblings, 0 replies; 31+ messages in thread
From: Willgerodt, Felix @ 2023-11-09 14:35 UTC (permalink / raw)
To: Simon Marchi, Andrew Burgess, gdb-patches; +Cc: Siddhesh Poyarekar
> > 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
First off thanks for doing this Andrew! I am very much in favor of your
proposed SECURITY file.
Can the file explicitly mention the static inspection case that Simon
brought up?
To me, it is pretty clear that untrusted binaries that you run in GDB are
out of scope, as you already actively chose to run untrusted code.
However I think the static case is much less clear for many people.
Being more explicit about it could help with that.
FYI, the binutils file has written this:
"Bugs in inspection tools (eg readelf, nm objdump) will not be considered
to be security bugs, since they do not create executable output
files."
(I personally think their reasoning is a bit vague, but that is another topic.)
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 19:34 ` Simon Marchi
2023-11-06 20:09 ` Siddhesh Poyarekar
2023-11-09 14:35 ` Willgerodt, Felix
@ 2023-11-16 17:19 ` Andrew Burgess
2023-11-16 17:27 ` Paul Koning
2 siblings, 1 reply; 31+ messages in thread
From: Andrew Burgess @ 2023-11-16 17:19 UTC (permalink / raw)
To: Simon Marchi, gdb-patches; +Cc: Siddhesh Poyarekar, felix.willgerodt
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-16 17:19 ` Andrew Burgess
@ 2023-11-16 17:27 ` Paul Koning
2023-11-16 21:35 ` Siddhesh Poyarekar
0 siblings, 1 reply; 31+ messages in thread
From: Paul Koning @ 2023-11-16 17:27 UTC (permalink / raw)
To: Andrew Burgess
Cc: Simon Marchi, gdb-patches, Siddhesh Poyarekar, felix.willgerodt
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-16 17:27 ` Paul Koning
@ 2023-11-16 21:35 ` Siddhesh Poyarekar
0 siblings, 0 replies; 31+ messages in thread
From: Siddhesh Poyarekar @ 2023-11-16 21:35 UTC (permalink / raw)
To: Paul Koning; +Cc: Andrew Burgess, Simon Marchi, gdb-patches, felix.willgerodt
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-11-06 13:26 [RFC] Adding a SECURITY policy for GDB Andrew Burgess
2023-11-06 18:55 ` Kevin Buettner
2023-11-06 19:34 ` Simon Marchi
@ 2023-12-08 15:05 ` Andrew Burgess
2023-12-09 10:55 ` Eli Zaretskii
` (4 more replies)
2 siblings, 5 replies; 31+ messages in thread
From: Andrew Burgess @ 2023-12-08 15:05 UTC (permalink / raw)
To: gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
Hello!
Apologies for taking so long to get a second version of this document
prepared. I've been through several iterations of this text since I
last posted trying to get something semi-reasonable... It would be great
to get your feedback on this new text.
This is basically a complete rewrite since V1, I'll try cover how this
new text addresses the feedback on V1:
1. A part of the original hope was that I could write some text that
would allow bugs triggered by just loading a binary into GDB (but not
running it) as non-security bugs. Why? Well, most of the bugs we
see in this area are from folk throwing fuzzed binaries at GDB,
raising a bug, and then raising a CVE on the back of that. The
first part of this process is useful for sure. The CVE part is just
a resource drain for downstream distributions.
I did make several attempts to write some text that would classify
bugs in this way ... but, to be honest, after about my fourth
attempt, all I'd managed to do was convince myself that this was not
a good idea.
So, instead, I've just given up on that. I think Simon, Paul, and
Felix should find (at least this part of) the new text satisfactory;
loading a binary, but not executing it, should be safe to do, and if
that's not the case, then this is a security issue.
2. As an aside, but not really relevant to the new text, given my
evolving position, I would say that I now disagree with the binutils
SECURITY position w.r.t. tools like objdump and readelf that Felix
mentioned. I think it's not unreasonable that a user might run an
analysis tool on an untrusted binary, and if such a tool can be
tricked (via a bug) into executing code, even with the permissions
of the original user, then I would see this as a security risk.
3. Kevin asked for discussion about running crash diagnostic tools that
wrap around GDB. I believe this is covered by the new text which
discusses in more detail how to safely run against trusted vs
untrusted binaries. Kevin: If you feel there are still things
missing that you'd like to see, then maybe you could suggest at
least some bullet points for what should be said, and I'll have a go
at fleshing it out.
One last thing, while writing this, I did wonder if this text would be
better moved into the GDB manual, and the gdb/SECURITY.txt document
should just say "See the GDB manual", but I figure that's a problem for
future me, for now I just need to find some words we can all agree on.
Thanks,
Andrew
----
GNU Debugger Security Policy
============================
Introduction
------------
The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
another program. This can be done by controlling the execution of
the program being debugged and allowing the user to inspect and
modify the state of the running program. Or GDB can be used to
analyse the program or a core file generated from the program
without needing to execute the program.
The program being debugged may be local i.e. on the system on which
GDB runs or remote, on a different system.
Policy Objectives
-----------------
The objective of this policy is define what the GDB project
considers a security bug and what is a non-security bug, and how
each category of bug should be reported.
Additionally, this policy will give some general advice to users on
how to use GDB securely.
Scope Of This Policy
--------------------
This policy covers all currently supported versions of GDB as
released from the official GDB website and covers gdb, gdbserver, as
well as gcore and gdb-add-index, which are packaged with each GDB
release. The official GDB website can be found here:
https://sourceware.org/gdb/
Remote debugging uses GDB to connect to a remote target. GDB sends
commands to the remote target which then controls the remote target.
The GDB project provides one remote target, gdbserver, which is
included with official GDB releases. Bugs within gdbserver are in
scope for this policy.
Other projects also implement remote targets to which GDB can
connect. Any bugs in these remote targets are out of scope for this
policy and should be reported to the relevant project. Any bugs in
GDB caused by a misbehaving remote target, even when that target is
not gdbserver, are in scope for this policy.
What Is Not A Security Bug?
---------------------------
In the context of local debugging, when GDB is used to execute a
program, the program runs with the same privileges as GDB itself.
Running a program through GDB is no different than running a program
directly. If debugging an untrusted program then the user should
ensure that this is done in a secure environment. Additionally, it
is possible for a program to detect when it is run under GDB and to
change its behaviour, unwanted behaviour may only appear when a
program is run under GDB.
Any issues that arise from running an untrusted binary are not
security bugs in GDB.
In the context of remote debugging, the program being debugged is
run with the same privileges as gdbserver. As with GDB in the local
debugging case, any issues that arise from running an untrusted
binary via gdbserver are not not security bugs in gdbserver.
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.
Any issues that arise due to a failure to protect the connection
between GDB and a remote target are not security bugs.
What Is A Security Bug?
-----------------------
Any bugs in GDB or gdbserver that result in an unexpected 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.
Any bugs in GDB that result in execution of the program being
debugged without a user issued GDB command triggering execution
(either from the GDB command line, a GDB configuration file, or from
the GDB prompt) are considered security bugs.
When gdbserver is started, if it is passed a program on its command
line then that program will be started, but paused before executing
its first instruction. Any bug which results in execution of the
program being debugged without GDB first connecting to the target
and sending a command that is intended to trigger execution is a
security bug in gdbserver.
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed,
for example, by simply loading the program into GDB or gdbserver, is
considered a security bug.
The additional tools gcore and gdb-add-index are scripts that wrap
around GDB. Any issue in these tools that meet the above
definitions of a security bug, are considered a security bug.
Security Considerations
-----------------------
Within this section, mention of GDB should be read as meaning GDB,
gdbserver, gcore, or gdb-add-index, unless specifically stated
otherwise.
The most common use case for GDB is a developer trying to resolve
issues within a program that they have either written themselves, or
within a program that they trust not to be malicious. In this
situation we would say GDB is being used to debug trusted code.
There is no greater security risk from running the program to debug
through GDB than there is running the program directly. Additional
process isolation for the GDB process is only needed if additional
isolation would have been applied anyway when running the program to
debug.
In some cases a developer may be given a program from an untrusted
source and be asked to debug an issue. In this situation we would
say GDB is being used to debug untrusted code. In this case the
user should take all the precautions when running GDB that they
would normally take when running an untrusted program outside of
GDB, e.g. running within a sandboxed environment.
When using GDB or to examine an untrusted program (with gdbserver,
the program can be started, but paused at the first instruction and
never run), there should be no security risk, however, there are two
things to consider:
1. The risk of inadvertently executing the untrusted program. It
would be easy for a user to accidentally issue one of the many
commands that would start the untrusted program executing. Even
the 'start' command, which stops the program being debugged at
the start of the main function might not be safe, a program can
embed a malicious payload before the main function is reached.
2. It is possible that a malicious executable could trigger a bug in
GDB to perform a malicious action. Such a bug would be a
security bug, but it would be best practice to guard against such
a bug if possible.
Given these risks, the advice of the GDB project is, when using GDB
with an untrusted binary, to do so in a sandboxed environment.
When using GDB and gdbserver to perform remote debug, the connection
between the two components in by design insecure. It is up to the
user to protect this connection, for example, only starting
gdbserver within a secure network.
Reporting Non-Security Bugs
---------------------------
NOTE: All bugs reported in the GDB Bugzilla are public.
Non-security bugs, as well as any security bugs that pose limited
risk to users should be reported in GDB's bugzilla system. Bugs
reported in this way will be public. The bugzilla system can be
found here:
https://sourceware.org/bugzilla/
Reporting Security Bugs
-----------------------
In order to report a private security bug that is not immediately
public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle
such bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is likely
that the team will ask to file a public bug because the issue is
sufficiently minor and does not warrant an embargo. An embargo is not
a requirement for being credited with the discovery of a security
vulnerability.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-12-08 15:05 ` Andrew Burgess
@ 2023-12-09 10:55 ` Eli Zaretskii
2024-02-04 15:32 ` Andrew Burgess
2023-12-12 7:27 ` Willgerodt, Felix
` (3 subsequent siblings)
4 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2023-12-09 10:55 UTC (permalink / raw)
To: Andrew Burgess
Cc: gdb-patches, siddhesh, kevinb, simark, felix.willgerodt, paulkoning
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>, Kevin Buettner
> <kevinb@redhat.com>, Simon Marchi <simark@simark.ca>,
> felix.willgerodt@intel.com, Paul Koning <paulkoning@comcast.net>
> Date: Fri, 08 Dec 2023 15:05:35 +0000
>
> Remote debugging uses GDB to connect to a remote target. GDB sends
> commands to the remote target which then controls the remote target.
The last sentence above has some kind of typo in it: it basically says
that "remote target controls the remote target", which makes no sense.
So either "controls" should be "control" (plural), which would then
mean it refers to "commands", or the sentence should be reworded to
clarify the meaning (perhaps it conflated between gdbserver and the
program it controls?)
> Other projects also implement remote targets to which GDB can
> connect. Any bugs in these remote targets are out of scope for this
> policy and should be reported to the relevant project. Any bugs in
> GDB caused by a misbehaving remote target, even when that target is
> not gdbserver, are in scope for this policy.
I suggest to prepend "However," to the last sentence, to make it clear
that it is contrary to the sentence before it.
> In the context of local debugging, when GDB is used to execute a
> program, the program runs with the same privileges as GDB itself.
> Running a program through GDB is no different than running a program
> directly. If debugging an untrusted program then the user should
> ensure that this is done in a secure environment.
Suggest to reword the last two sentence into one:
Since running a program through GDB is no different from running a
program directly, it follows that when debugging an untrusted
program, the user should ensure that this is done in a secure
environment.
> Additionally, it
> is possible for a program to detect when it is run under GDB and to
> change its behaviour, unwanted behaviour may only appear when a
> program is run under GDB.
I don't think I understand what this attempts to say. Maybe this
sentence should be moved to after the previous one. Like this:
Running a program through GDB is no different than running a program
directly. Additionally, it is possible for a program to detect when
it is run under GDB and to change its behavior, so that the unwanted
behavior may only appear when a program is run under GDB.
Therefore, when debugging an untrusted program, the user should
ensure that this is done in a secure environment.
> Any issues that arise from running an untrusted binary are not
> security bugs in GDB.
This is too general, I think. Perhaps you meant
Any issues that arise from running an untrusted binary not inside a
secure environment are not security bugs in GDB.
> In the context of remote debugging, the program being debugged is
> run with the same privileges as gdbserver. As with GDB in the local
> debugging case, any issues that arise from running an untrusted
> binary via gdbserver are not not security bugs in gdbserver.
Same here: too general?
> The connection between GDB and a remote target is not protected by
> either authentication, or encryption.
^
That comma is redundant and should be deleted.
> 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.
There should be a comma after "As such" in the last sentence,
otherwise it reads as an incomplete sentence.
> Any issues that arise due to a failure to protect the connection
> between GDB and a remote target are not security bugs.
^^^^^^^^^^^^^^^^^^^^^
"are not security bugs in GDB."
> Any bugs in GDB or gdbserver that result in an unexpected crossing
> of a privilege boundary are considered security bugs. Some examples
> of crossing a privilege boundary include; being able to execute code
^
That semi-colon should be a colon.
> Any bugs in GDB that result in execution of the program being
> debugged without a user issued GDB command triggering execution
^^^^^^
"issuing"
> (either from the GDB command line, a GDB configuration file, or from
> the GDB prompt) are considered security bugs.
Is any execution of the program triggered by starting GDB considered
"a command issued by the user"? IOW, are we sure GDB will never cause
some program code to be executed just as result of the user saying
$ gdb ./program
? The above text seems to assume that any such execution at startup
must be the result of some command-line argument or some configuration
file, but is that 110% certain, and are we sure this will _never_
change?
> Any bug in GDB or gdbserver that can trigger arbitrary code
> execution without the program being debugged having been executed,
> for example, by simply loading the program into GDB or gdbserver, is
> considered a security bug.
Similar issue here: when this says "having been executed", does it
mean executed explicitly by a user command, or does it also mean
executed as part of the administrivia of loading the program?
> Within this section, mention of GDB should be read as meaning GDB,
^^^^^^^^^^^^^^
"references to GDB", not "mention of GDB"
> In some cases a developer may be given a program from an untrusted
> source and be asked to debug an issue. In this situation we would
> say GDB is being used to debug untrusted code. In this case the
> user should take all the precautions when running GDB that they
> would normally take when running an untrusted program outside of
> GDB, e.g. running within a sandboxed environment.
This text contradicts the remark above that a malicious program could
change its behavior when running under GDB.
> When using GDB or to examine an untrusted program (with gdbserver,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Something is wrong here: some word missing or maybe "or" should be
deleted.
> 2. It is possible that a malicious executable could trigger a bug in
> GDB to perform a malicious action. Such a bug would be a
^^^^^^^^^^^^^^^^^^^^^
Did you mean "would not be"? otherwise this sentence makes no sense,
because of what follows starts with "but":
> security bug, but it would be best practice to guard against such
> a bug if possible.
> When using GDB and gdbserver to perform remote debug, the connection
> between the two components in by design insecure. It is up to the
^^
"is"
> In order to report a private security bug that is not immediately
> public, please contact one of the downstream distributions with
"immediately public"? what's that?
> The team contacted will take care of details such as vulnerability
> rating and CVE assignment (http://cve.mitre.org/about/). It is likely
> that the team will ask to file a public bug because the issue is
> sufficiently minor and does not warrant an embargo. An embargo is not
> a requirement for being credited with the discovery of a security
> vulnerability.
This doesn't explain what is "embargo". Should it? I, for one, don't
know what that means.
Thanks.
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [RFC] Adding a SECURITY policy for GDB
2023-12-08 15:05 ` Andrew Burgess
2023-12-09 10:55 ` Eli Zaretskii
@ 2023-12-12 7:27 ` Willgerodt, Felix
2024-02-04 15:36 ` [V3] " Andrew Burgess
` (2 subsequent siblings)
4 siblings, 0 replies; 31+ messages in thread
From: Willgerodt, Felix @ 2023-12-12 7:27 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi, Paul Koning
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Freitag, 8. Dezember 2023 16:06
> To: gdb-patches@sourceware.org
> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>; Kevin Buettner
> <kevinb@redhat.com>; Simon Marchi <simark@simark.ca>; Willgerodt, Felix
> <felix.willgerodt@intel.com>; Paul Koning <paulkoning@comcast.net>
> Subject: Re: [RFC] Adding a SECURITY policy for GDB
>
>
> Hello!
>
> Apologies for taking so long to get a second version of this document
> prepared. I've been through several iterations of this text since I
> last posted trying to get something semi-reasonable... It would be great
> to get your feedback on this new text.
>
> This is basically a complete rewrite since V1, I'll try cover how this
> new text addresses the feedback on V1:
>
> 1. A part of the original hope was that I could write some text that
> would allow bugs triggered by just loading a binary into GDB (but not
> running it) as non-security bugs. Why? Well, most of the bugs we
> see in this area are from folk throwing fuzzed binaries at GDB,
> raising a bug, and then raising a CVE on the back of that. The
> first part of this process is useful for sure. The CVE part is just
> a resource drain for downstream distributions.
>
> I did make several attempts to write some text that would classify
> bugs in this way ... but, to be honest, after about my fourth
> attempt, all I'd managed to do was convince myself that this was not
> a good idea.
>
> So, instead, I've just given up on that. I think Simon, Paul, and
> Felix should find (at least this part of) the new text satisfactory;
> loading a binary, but not executing it, should be safe to do, and if
> that's not the case, then this is a security issue.
>
> 2. As an aside, but not really relevant to the new text, given my
> evolving position, I would say that I now disagree with the binutils
> SECURITY position w.r.t. tools like objdump and readelf that Felix
> mentioned. I think it's not unreasonable that a user might run an
> analysis tool on an untrusted binary, and if such a tool can be
> tricked (via a bug) into executing code, even with the permissions
> of the original user, then I would see this as a security risk.
>
> 3. Kevin asked for discussion about running crash diagnostic tools that
> wrap around GDB. I believe this is covered by the new text which
> discusses in more detail how to safely run against trusted vs
> untrusted binaries. Kevin: If you feel there are still things
> missing that you'd like to see, then maybe you could suggest at
> least some bullet points for what should be said, and I'll have a go
> at fleshing it out.
>
> One last thing, while writing this, I did wonder if this text would be
> better moved into the GDB manual, and the gdb/SECURITY.txt document
> should just say "See the GDB manual", but I figure that's a problem for
> future me, for now I just need to find some words we can all agree on.
>
> Thanks,
> Andrew
Hi Andrew,
Thanks again for taking the time to write this! I think the new text is great
and I am in favor of it.
Regards,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-12-09 10:55 ` Eli Zaretskii
@ 2024-02-04 15:32 ` Andrew Burgess
2024-02-04 17:18 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Andrew Burgess @ 2024-02-04 15:32 UTC (permalink / raw)
To: Eli Zaretskii
Cc: gdb-patches, siddhesh, kevinb, simark, felix.willgerodt, paulkoning
Eli,
Thanks for all your feedback. Sorry it's taken me so long to get back
around to looking at this. Most of the issues you highlighted are
straight forward fixes, but I do have a couple of follow up questions,
see inline below...
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>, Kevin Buettner
>> <kevinb@redhat.com>, Simon Marchi <simark@simark.ca>,
>> felix.willgerodt@intel.com, Paul Koning <paulkoning@comcast.net>
>> Date: Fri, 08 Dec 2023 15:05:35 +0000
>>
>> Remote debugging uses GDB to connect to a remote target. GDB sends
>> commands to the remote target which then controls the remote target.
>
> The last sentence above has some kind of typo in it: it basically says
> that "remote target controls the remote target", which makes no sense.
>
> So either "controls" should be "control" (plural), which would then
> mean it refers to "commands", or the sentence should be reworded to
> clarify the meaning (perhaps it conflated between gdbserver and the
> program it controls?)
>
>> Other projects also implement remote targets to which GDB can
>> connect. Any bugs in these remote targets are out of scope for this
>> policy and should be reported to the relevant project. Any bugs in
>> GDB caused by a misbehaving remote target, even when that target is
>> not gdbserver, are in scope for this policy.
>
> I suggest to prepend "However," to the last sentence, to make it clear
> that it is contrary to the sentence before it.
>
>> In the context of local debugging, when GDB is used to execute a
>> program, the program runs with the same privileges as GDB itself.
>> Running a program through GDB is no different than running a program
>> directly. If debugging an untrusted program then the user should
>> ensure that this is done in a secure environment.
>
> Suggest to reword the last two sentence into one:
>
> Since running a program through GDB is no different from running a
> program directly, it follows that when debugging an untrusted
> program, the user should ensure that this is done in a secure
> environment.
>
>> Additionally, it
>> is possible for a program to detect when it is run under GDB and to
>> change its behaviour, unwanted behaviour may only appear when a
>> program is run under GDB.
>
> I don't think I understand what this attempts to say. Maybe this
> sentence should be moved to after the previous one. Like this:
>
> Running a program through GDB is no different than running a program
> directly. Additionally, it is possible for a program to detect when
> it is run under GDB and to change its behavior, so that the unwanted
> behavior may only appear when a program is run under GDB.
> Therefore, when debugging an untrusted program, the user should
> ensure that this is done in a secure environment.
>
>> Any issues that arise from running an untrusted binary are not
>> security bugs in GDB.
>
> This is too general, I think. Perhaps you meant
>
> Any issues that arise from running an untrusted binary not inside a
> secure environment are not security bugs in GDB.
>
>> In the context of remote debugging, the program being debugged is
>> run with the same privileges as gdbserver. As with GDB in the local
>> debugging case, any issues that arise from running an untrusted
>> binary via gdbserver are not not security bugs in gdbserver.
>
> Same here: too general?
>
>> The connection between GDB and a remote target is not protected by
>> either authentication, or encryption.
> ^
> That comma is redundant and should be deleted.
>
>> 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.
>
> There should be a comma after "As such" in the last sentence,
> otherwise it reads as an incomplete sentence.
>
>> Any issues that arise due to a failure to protect the connection
>> between GDB and a remote target are not security bugs.
> ^^^^^^^^^^^^^^^^^^^^^
> "are not security bugs in GDB."
>
>> Any bugs in GDB or gdbserver that result in an unexpected crossing
>> of a privilege boundary are considered security bugs. Some examples
>> of crossing a privilege boundary include; being able to execute code
> ^
> That semi-colon should be a colon.
>
>> Any bugs in GDB that result in execution of the program being
>> debugged without a user issued GDB command triggering execution
> ^^^^^^
> "issuing"
>
>> (either from the GDB command line, a GDB configuration file, or from
>> the GDB prompt) are considered security bugs.
>
> Is any execution of the program triggered by starting GDB considered
> "a command issued by the user"? IOW, are we sure GDB will never cause
> some program code to be executed just as result of the user saying
>
> $ gdb ./program
>
> ? The above text seems to assume that any such execution at startup
> must be the result of some command-line argument or some configuration
> file, but is that 110% certain, and are we sure this will _never_
> change?
Am I 110% certain? No. I'm never going to claim that level of
certainty on a topic. But I am 99% certain.
Am I sure this will _never change? No. But that's OK.
This document is about writing down an agreed project position on this
behaviour today.
If tomorrow someone wants to propose a patch where 'gdb ./prog' would
automatically run './prog' then they are welcome to do so. But part of
that patch would require updating the SECURITY.txt document, and
hopefully, by touching the SECURITY.txt document, this would trigger a
conversation about whether we actually wanted to make that change.
But that doesn't mean this document cannot be changed.
FYI, right now, if someone did propose such a patch, I would be against
it being merged due to the possible security implications.
>
>> Any bug in GDB or gdbserver that can trigger arbitrary code
>> execution without the program being debugged having been executed,
>> for example, by simply loading the program into GDB or gdbserver, is
>> considered a security bug.
>
> Similar issue here: when this says "having been executed", does it
> mean executed explicitly by a user command, or does it also mean
> executed as part of the administrivia of loading the program?
I reworded this as:
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed by
a user command, would be considered a security bug. For example, if
simply loading a program into GDB could trigger arbitrary code
execution, then this would be a security issue.
This is just trying to reinforce the point that _unless_ the user types
'run' (or equivalent) then there should be no arbitrary code execution
as a result of simply loading the program, or inspecting the program.
>
>> Within this section, mention of GDB should be read as meaning GDB,
> ^^^^^^^^^^^^^^
> "references to GDB", not "mention of GDB"
>
>> In some cases a developer may be given a program from an untrusted
>> source and be asked to debug an issue. In this situation we would
>> say GDB is being used to debug untrusted code. In this case the
>> user should take all the precautions when running GDB that they
>> would normally take when running an untrusted program outside of
>> GDB, e.g. running within a sandboxed environment.
>
> This text contradicts the remark above that a malicious program could
> change its behavior when running under GDB.
>
>> When using GDB or to examine an untrusted program (with gdbserver,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Something is wrong here: some word missing or maybe "or" should be
> deleted.
>
>> 2. It is possible that a malicious executable could trigger a bug in
>> GDB to perform a malicious action. Such a bug would be a
> ^^^^^^^^^^^^^^^^^^^^^
> Did you mean "would not be"? otherwise this sentence makes no sense,
> because of what follows starts with "but":
>
>> security bug, but it would be best practice to guard against such
>> a bug if possible.
I reworded this paragraph as:
2. Though every effort is made to ensure GDB is free from bugs, it
cannot be guaranteed that GDB is bug free. It might be possible
that even examining an untrusted program could trigger a bug in
GDB which, in turn could trigger an unwanted effect on the system
running GDB.
What I'm trying to say here is that, though you _should_ be free to load
and examine an untrusted binary in GDB, the reality is that GDB is not
hardened against malicious binaries, e.g. using a fuzzing tool to
generate invalid binaries will often trigger buffer overflow issues in
GDB. Potentially these _might_ be exploitable to trigger arbitrary code
execution.
I feel, as a project we might want to say that it is safe to load an
untrusted binary, in reality, if someone is looking to be 100% secure,
then even inspecting an untrusted binary should be done in a sandboxed
environment.
>
>> When using GDB and gdbserver to perform remote debug, the connection
>> between the two components in by design insecure. It is up to the
> ^^
> "is"
>
>> In order to report a private security bug that is not immediately
>> public, please contact one of the downstream distributions with
>
> "immediately public"? what's that?
>
>> The team contacted will take care of details such as vulnerability
>> rating and CVE assignment (http://cve.mitre.org/about/). It is likely
>> that the team will ask to file a public bug because the issue is
>> sufficiently minor and does not warrant an embargo. An embargo is not
>> a requirement for being credited with the discovery of a security
>> vulnerability.
>
> This doesn't explain what is "embargo". Should it? I, for one, don't
> know what that means.
In this context it just means to keep the details private.
I reworked this to remove use of the word "embargo", I actually stole
this bit of text from the binutils SECURITY.txt file, but on re-reading
I feel it would be better written in plainer language, so that's what
I've done.
I'll post a V3 shortly which contains all of my updates.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [V3] [RFC] Adding a SECURITY policy for GDB
2023-12-08 15:05 ` Andrew Burgess
2023-12-09 10:55 ` Eli Zaretskii
2023-12-12 7:27 ` Willgerodt, Felix
@ 2024-02-04 15:36 ` Andrew Burgess
2024-02-18 13:55 ` Andrew Burgess
2024-02-05 21:01 ` Tom Tromey
2024-02-12 16:43 ` Guinevere Larsen
4 siblings, 1 reply; 31+ messages in thread
From: Andrew Burgess @ 2024-02-04 15:36 UTC (permalink / raw)
To: gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
Here is a V3 proposal for a SECURITY.txt document.
There is much less change from V2 to V3 than V1 to V2. This was really
me going through and addressing Eli's feedback. There are still a
couple of open questions from Eli's feedback, so further updates may be
need in the future, hopefully I can get later revisions out quicker than
V3.
All feedback would be great.
Thanks,
Andrew
--
GNU Debugger Security Policy
============================
Introduction
------------
The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
another program. This can be done by controlling the execution of
the program being debugged and allowing the user to inspect and
modify the state of the running program. Or GDB can be used to
analyse the program or a core file generated from the program
without needing to execute the program.
The program being debugged may be local i.e. on the system on which
GDB runs or remote, on a different system.
Policy Objectives
-----------------
The objective of this policy is define what the GDB project
considers a security bug and what is a non-security bug, and how
each category of bug should be reported.
Additionally, this policy will give some general advice to users on
how to use GDB securely.
Scope Of This Policy
--------------------
This policy covers all currently supported versions of GDB as
released from the official GDB website and covers gdb, gdbserver, as
well as gcore and gdb-add-index, which are packaged with each GDB
release. The official GDB website can be found here:
https://sourceware.org/gdb/
Remote debugging uses GDB to connect to a remote target. GDB sends
commands to the remote target which then controls the process being
debugged. The GDB project provides one remote target, gdbserver,
which is included with official GDB releases. Bugs within gdbserver
are in scope for this policy.
Other projects also implement remote targets to which GDB can
connect. Any bugs in these remote targets are out of scope for this
policy and should be reported to the relevant project. However, any
bugs in GDB caused by a misbehaving remote target, even when that
target is not gdbserver, are in scope for this policy.
What Is Not A Security Bug?
---------------------------
In the context of local debugging, when GDB is used to execute a
program, the program runs with the same privileges as GDB itself.
Additionally, it is possible for a program to detect when it is run
under GDB and to change its behavior, so that unwanted behavior may
only appear when a program is run under GDB. Therefore, when
debugging an untrusted program, the user should ensure that this is
done in a secure environment.
Any issues that arise from running an untrusted binary not inside a
secure environment are not security bugs in GDB.
In the context of remote debugging, the program being debugged is
run with the same privileges as gdbserver. As with GDB in the local
debugging case, any issues that arise from running an untrusted
binary not inside a secure environment are not security bugs in
gdbserver.
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.
Any issues that arise due to a failure to protect the connection
between GDB and a remote target are not security bugs in either GDB
or gdbserver.
What Is A Security Bug?
-----------------------
Any bugs in GDB or gdbserver that result in an unexpected 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.
Any bugs in GDB that result in execution of the program being
debugged without the user issuing a GDB command triggering execution
(either from the GDB command line, a GDB configuration file, or from
the GDB prompt) are considered security bugs.
When gdbserver is started, if it is passed a program on its command
line then that program will be started, but paused before executing
its first instruction. Any bug which results in execution of the
program being debugged without GDB first connecting to the target
and sending a command that is intended to trigger execution is a
security bug in gdbserver.
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed by
a user command, would be considered a security bug. For example, if
simply loading a program into GDB could trigger arbitrary code
execution, then this would be a security issue.
The additional tools gcore and gdb-add-index are scripts that wrap
around GDB. Any issue in these tools that meet the above
definitions of a security bug, are considered a security bug.
Security Considerations
-----------------------
Within this section, references to GDB should be read as meaning
GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
otherwise.
The most common use case for GDB is a developer trying to resolve
issues within a program that they have either written themselves, or
within a program that they trust not to be malicious. In this
situation we would say GDB is being used to debug trusted code.
There is no greater security risk from running the program to debug
through GDB than there is running the program directly. Additional
process isolation for the GDB process is only needed if additional
isolation would have been applied anyway when running the program to
debug.
In some cases a developer may be given a program from an untrusted
source and be asked to debug an issue. In this situation we would
say GDB is being used to debug untrusted code. In this case the
user should take all the precautions when running GDB that they
would normally take when running an untrusted program outside of
GDB, e.g. running within a secure, sandboxed environment.
When using GDB to examine an untrusted program (with gdbserver, the
program can be started, but paused at the first instruction and
never run further), there should be no security risk, however, there
are two things to consider:
1. The risk of inadvertently executing the untrusted program. It
would be easy for a user to accidentally issue one of the many
commands that would start the untrusted program executing. Even
the 'start' command, which stops the program being debugged at
the start of the main function might not be safe, a program can
embed a malicious payload before the main function is reached.
2. Though every effort is made to ensure GDB is free from bugs, it
cannot be guaranteed that GDB is bug free. It might be possible
that even examining an untrusted program could trigger a bug in
GDB which, in turn could trigger an unwanted effect on the system
running GDB.
Given these risks, the advice of the GDB project is, when using GDB
with an untrusted binary, to do so in a secure, sandboxed environment.
When using GDB and gdbserver to perform remote debug, the connection
between the two components is by design insecure. It is up to the
user to protect this connection, for example, only starting
gdbserver within a secure network.
Reporting Non-Security Bugs
---------------------------
NOTE: All bugs reported in the GDB Bugzilla are public.
Non-security bugs, as well as any security bugs that pose limited
risk to users should be reported in GDB's bugzilla system. Bugs
reported in this way will be public. The bugzilla system can be
found here:
https://sourceware.org/bugzilla/
Reporting Security Bugs
-----------------------
In order to report a private security bug that is not immediately
made public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle such
bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is
likely that the team will ask to file a public bug because the issue
is sufficiently minor and does not warrant keeping details of the
bug private.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-04 15:32 ` Andrew Burgess
@ 2024-02-04 17:18 ` Eli Zaretskii
2024-02-04 17:43 ` Andreas Schwab
2024-02-05 11:06 ` Andrew Burgess
0 siblings, 2 replies; 31+ messages in thread
From: Eli Zaretskii @ 2024-02-04 17:18 UTC (permalink / raw)
To: Andrew Burgess
Cc: gdb-patches, siddhesh, kevinb, simark, felix.willgerodt, paulkoning
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com,
> simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net
> Date: Sun, 04 Feb 2024 15:32:58 +0000
>
> >> Any bugs in GDB that result in execution of the program being
> >> debugged without a user issued GDB command triggering execution
> > ^^^^^^
> > "issuing"
> >
> >> (either from the GDB command line, a GDB configuration file, or from
> >> the GDB prompt) are considered security bugs.
> >
> > Is any execution of the program triggered by starting GDB considered
> > "a command issued by the user"? IOW, are we sure GDB will never cause
> > some program code to be executed just as result of the user saying
> >
> > $ gdb ./program
> >
> > ? The above text seems to assume that any such execution at startup
> > must be the result of some command-line argument or some configuration
> > file, but is that 110% certain, and are we sure this will _never_
> > change?
>
> Am I 110% certain? No. I'm never going to claim that level of
> certainty on a topic. But I am 99% certain.
>
> Am I sure this will _never change? No. But that's OK.
>
> This document is about writing down an agreed project position on this
> behaviour today.
>
> If tomorrow someone wants to propose a patch where 'gdb ./prog' would
> automatically run './prog' then they are welcome to do so. But part of
> that patch would require updating the SECURITY.txt document, and
> hopefully, by touching the SECURITY.txt document, this would trigger a
> conversation about whether we actually wanted to make that change.
>
> But that doesn't mean this document cannot be changed.
>
> FYI, right now, if someone did propose such a patch, I would be against
> it being merged due to the possible security implications.
What bothered me here is that when you say "gdb ./program", GDB can do
two things which constitute code execution:
. run some startup code in the program, for example, load some
shared libraries, which could trigger execution of some code in
those libraries, or
. process various init files, which could invoke code in
Python/Guile, or call functions inside the debuggee
The second item actually happens when you say "gdb ./emacs" in the src
directory of an Emacs source tree, because there's a .gdbinit file
that which can call functions inside the executable and/or run Python
code. Are these cases relevant to this part of the policy?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-04 17:18 ` Eli Zaretskii
@ 2024-02-04 17:43 ` Andreas Schwab
2024-02-04 18:56 ` Eli Zaretskii
2024-02-05 11:06 ` Andrew Burgess
1 sibling, 1 reply; 31+ messages in thread
From: Andreas Schwab @ 2024-02-04 17:43 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Andrew Burgess, gdb-patches, siddhesh, kevinb, simark,
felix.willgerodt, paulkoning
On Feb 04 2024, Eli Zaretskii wrote:
> What bothered me here is that when you say "gdb ./program", GDB can do
> two things which constitute code execution:
>
> . run some startup code in the program, for example, load some
> shared libraries, which could trigger execution of some code in
> those libraries, or
> . process various init files, which could invoke code in
> Python/Guile, or call functions inside the debuggee
>
> The second item actually happens when you say "gdb ./emacs" in the src
> directory of an Emacs source tree, because there's a .gdbinit file
Not by default. It needs to be enabled by setting the auto-load
safe-path.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-04 17:43 ` Andreas Schwab
@ 2024-02-04 18:56 ` Eli Zaretskii
0 siblings, 0 replies; 31+ messages in thread
From: Eli Zaretskii @ 2024-02-04 18:56 UTC (permalink / raw)
To: Andreas Schwab
Cc: aburgess, gdb-patches, siddhesh, kevinb, simark,
felix.willgerodt, paulkoning
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org,
> siddhesh@redhat.com, kevinb@redhat.com, simark@simark.ca,
> felix.willgerodt@intel.com, paulkoning@comcast.net
> Date: Sun, 04 Feb 2024 18:43:07 +0100
>
> On Feb 04 2024, Eli Zaretskii wrote:
>
> > What bothered me here is that when you say "gdb ./program", GDB can do
> > two things which constitute code execution:
> >
> > . run some startup code in the program, for example, load some
> > shared libraries, which could trigger execution of some code in
> > those libraries, or
> > . process various init files, which could invoke code in
> > Python/Guile, or call functions inside the debuggee
> >
> > The second item actually happens when you say "gdb ./emacs" in the src
> > directory of an Emacs source tree, because there's a .gdbinit file
>
> Not by default. It needs to be enabled by setting the auto-load
> safe-path.
That's a subtlety that, if significant, should IMO be explicitly
mentioned, because otherwise talking about "user issuing a GDB command
triggering execution (either from the GDB command line, a GDB
configuration file, or from the GDB prompt)" does not necessarily
include the above. For example, the .gdbinit file that comes with
Emacs was not written by any particular user of GDB who happens to
debug Emacs.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-04 17:18 ` Eli Zaretskii
2024-02-04 17:43 ` Andreas Schwab
@ 2024-02-05 11:06 ` Andrew Burgess
1 sibling, 0 replies; 31+ messages in thread
From: Andrew Burgess @ 2024-02-05 11:06 UTC (permalink / raw)
To: Eli Zaretskii
Cc: gdb-patches, siddhesh, kevinb, simark, felix.willgerodt, paulkoning
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com,
>> simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net
>> Date: Sun, 04 Feb 2024 15:32:58 +0000
>>
>> >> Any bugs in GDB that result in execution of the program being
>> >> debugged without a user issued GDB command triggering execution
>> > ^^^^^^
>> > "issuing"
>> >
>> >> (either from the GDB command line, a GDB configuration file, or from
>> >> the GDB prompt) are considered security bugs.
>> >
>> > Is any execution of the program triggered by starting GDB considered
>> > "a command issued by the user"? IOW, are we sure GDB will never cause
>> > some program code to be executed just as result of the user saying
>> >
>> > $ gdb ./program
>> >
>> > ? The above text seems to assume that any such execution at startup
>> > must be the result of some command-line argument or some configuration
>> > file, but is that 110% certain, and are we sure this will _never_
>> > change?
>>
>> Am I 110% certain? No. I'm never going to claim that level of
>> certainty on a topic. But I am 99% certain.
>>
>> Am I sure this will _never change? No. But that's OK.
>>
>> This document is about writing down an agreed project position on this
>> behaviour today.
>>
>> If tomorrow someone wants to propose a patch where 'gdb ./prog' would
>> automatically run './prog' then they are welcome to do so. But part of
>> that patch would require updating the SECURITY.txt document, and
>> hopefully, by touching the SECURITY.txt document, this would trigger a
>> conversation about whether we actually wanted to make that change.
>>
>> But that doesn't mean this document cannot be changed.
>>
>> FYI, right now, if someone did propose such a patch, I would be against
>> it being merged due to the possible security implications.
>
> What bothered me here is that when you say "gdb ./program", GDB can do
> two things which constitute code execution:
>
> . run some startup code in the program, for example, load some
> shared libraries, which could trigger execution of some code in
> those libraries, or
In a pure GDB world I don't think this is correct. No inferior process
is created until some user command, from _somewhere_ tells GDB to start
a process. That might be from a `.gdbinit` file, but I have tried to
cover this case by referencing 'configuration files'.
No shared libraries will be loaded until the inferior process starts
running.
> . process various init files, which could invoke code in
> Python/Guile, or call functions inside the debuggee
>
> The second item actually happens when you say "gdb ./emacs" in the src
> directory of an Emacs source tree, because there's a .gdbinit file
> that which can call functions inside the executable and/or run Python
> code. Are these cases relevant to this part of the policy?
You are correct that loading a particular executable might auto-load a
configuration files, so maybe that needs to be specifically called out,
but I do consider this covered by my mention of 'configuration files'.
Without such a configuration files which starts the inferior then there
should be no inferior execution.
Maybe we do need to mention the auto-loading, and draw attention to the
auto-load safe-path stuff, I'll see if I can work something about this
in -- though I want to try and avoid being too specific, this isn't
intended as a "how too", but more a high level policy document, but I
think mentioning the idea of auto-loading, and that GDB will always make
such auto-loading "opt-in" rather than "opt-out" is certainly something
that the document should cover.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-12-08 15:05 ` Andrew Burgess
` (2 preceding siblings ...)
2024-02-04 15:36 ` [V3] " Andrew Burgess
@ 2024-02-05 21:01 ` Tom Tromey
2024-02-09 15:59 ` Andrew Burgess
2024-02-12 16:43 ` Guinevere Larsen
4 siblings, 1 reply; 31+ messages in thread
From: Tom Tromey @ 2024-02-05 21:01 UTC (permalink / raw)
To: Andrew Burgess
Cc: gdb-patches, Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
Andrew> Apologies for taking so long to get a second version of this document
Andrew> prepared. I've been through several iterations of this text since I
Andrew> last posted trying to get something semi-reasonable... It would be great
Andrew> to get your feedback on this new text.
Thank you for doing this.
Andrew> So, instead, I've just given up on that. I think Simon, Paul, and
Andrew> Felix should find (at least this part of) the new text satisfactory;
Andrew> loading a binary, but not executing it, should be safe to do, and if
Andrew> that's not the case, then this is a security issue.
I think this is what users expect, but I don't think this is at all in
line with what we can promise. We couldn't get consensus to deprecate
the stabs reader last year, but at the same time, nobody works on the
existing fuzzer bugs that have been reported against it (or was it
mdebugread?) ... the point being that there's a lot of
dead-but-vulnerable code.
For the DWARF reader, this safety might be attainable, though given the
large number of DWARF scenarios, I am skeptical. In any case, this
promise definitely doesn't describe the situation *today*, where nobody
has seriously tried fuzzing, or even really looking through the more
obvious possible buffer overruns.
To be clear, I'm not at all opposed to someone fixing fuzzer bugs. It's
clear to me that it ought to be done, even if it comes at some cost.
Perhaps this is covered by the section recommending sandboxing.
Andrew> One last thing, while writing this, I did wonder if this text would be
Andrew> better moved into the GDB manual, and the gdb/SECURITY.txt document
Andrew> should just say "See the GDB manual", but I figure that's a problem for
Andrew> future me, for now I just need to find some words we can all agree on.
I think this would be good.
Tom
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-05 21:01 ` Tom Tromey
@ 2024-02-09 15:59 ` Andrew Burgess
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Burgess @ 2024-02-09 15:59 UTC (permalink / raw)
To: Tom Tromey
Cc: gdb-patches, Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
Tom Tromey <tom@tromey.com> writes:
>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> Apologies for taking so long to get a second version of this document
> Andrew> prepared. I've been through several iterations of this text since I
> Andrew> last posted trying to get something semi-reasonable... It would be great
> Andrew> to get your feedback on this new text.
>
> Thank you for doing this.
>
> Andrew> So, instead, I've just given up on that. I think Simon, Paul, and
> Andrew> Felix should find (at least this part of) the new text satisfactory;
> Andrew> loading a binary, but not executing it, should be safe to do, and if
> Andrew> that's not the case, then this is a security issue.
>
> I think this is what users expect, but I don't think this is at all in
> line with what we can promise. We couldn't get consensus to deprecate
> the stabs reader last year, but at the same time, nobody works on the
> existing fuzzer bugs that have been reported against it (or was it
> mdebugread?) ... the point being that there's a lot of
> dead-but-vulnerable code.
>
> For the DWARF reader, this safety might be attainable, though given the
> large number of DWARF scenarios, I am skeptical. In any case, this
> promise definitely doesn't describe the situation *today*, where nobody
> has seriously tried fuzzing, or even really looking through the more
> obvious possible buffer overruns.
>
> To be clear, I'm not at all opposed to someone fixing fuzzer bugs. It's
> clear to me that it ought to be done, even if it comes at some cost.
>
> Perhaps this is covered by the section recommending sandboxing.
Thanks for your thoughts on this. What you've said is similar to
discussions I've had within Red Hat on this topic.
On one hand some argue the security policy should reflect the current
state of GDB, and bugs that are found in areas of GDB which are known to
be, maybe, not so robust, should not be classified as security bugs.
The interest of folk in this group are mostly about reducing the number
of security issues that are reported, so they'd like to see an upstream
security policy which lets bugs reported as "security" be reclassified
as "normal" upstream bugs.
Then there's the view which was reflected (I think) in the initial
feedback to my V1 proposal, and which is where I now sit. The security
policy should be aspirational, lay out how we'd like things to be, and
then, in theory, we can work towards that as a goal.
But reading what you write, I think maybe there's a third position which
sits somewhere between these two, and you're right that I do touch on
this third position when I discuss sandboxing, but maybe I don't stress
this enough? I should probably lay out where we'd like GDB to be, but
then be more open and realistic about where GDB actually is.
I think we're all agreeing that a user should be able to examine
(without running) an untrusted binary and have this be risk free. But
as you point out, and I don't think anyone will disagree with, right now
that isn't really a safe thing to do, and really folk shouldn't be doing
that.
I also have some notes from Eli to fold in, so I'll take another pass at
this next week and try to come up with a V4 which covers these ideas.
Thanks for your feedback,
Andrew
>
> Andrew> One last thing, while writing this, I did wonder if this text would be
> Andrew> better moved into the GDB manual, and the gdb/SECURITY.txt document
> Andrew> should just say "See the GDB manual", but I figure that's a problem for
> Andrew> future me, for now I just need to find some words we can all agree on.
>
> I think this would be good.
>
> Tom
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2023-12-08 15:05 ` Andrew Burgess
` (3 preceding siblings ...)
2024-02-05 21:01 ` Tom Tromey
@ 2024-02-12 16:43 ` Guinevere Larsen
2024-02-12 17:06 ` Siddhesh Poyarekar
4 siblings, 1 reply; 31+ messages in thread
From: Guinevere Larsen @ 2024-02-12 16:43 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
On 08/12/2023 16:05, Andrew Burgess wrote:
> One last thing, while writing this, I did wonder if this text would be
> better moved into the GDB manual, and the gdb/SECURITY.txt document
> should just say "See the GDB manual", but I figure that's a problem for
> future me, for now I just need to find some words we can all agree on.
>
> Thanks,
> Andrew
Would it be possible to do the opposite and have the docs pull from the
txt document? I like the idea of having specific files that are easy to
check as a developer or end user, and I think having a file that says
"look at that other file" that contains everything GDB (and thus makes
it harder to quickly find what you're looking for) would muddle that a
little bit.
--
Cheers,
Guinevere Larsen
She/Her/Hers
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-12 16:43 ` Guinevere Larsen
@ 2024-02-12 17:06 ` Siddhesh Poyarekar
2024-02-14 15:03 ` Andrew Burgess
0 siblings, 1 reply; 31+ messages in thread
From: Siddhesh Poyarekar @ 2024-02-12 17:06 UTC (permalink / raw)
To: Guinevere Larsen, Andrew Burgess, gdb-patches
Cc: Kevin Buettner, Simon Marchi, felix.willgerodt, Paul Koning
On 2024-02-12 11:43, Guinevere Larsen wrote:
> On 08/12/2023 16:05, Andrew Burgess wrote:
>> One last thing, while writing this, I did wonder if this text would be
>> better moved into the GDB manual, and the gdb/SECURITY.txt document
>> should just say "See the GDB manual", but I figure that's a problem for
>> future me, for now I just need to find some words we can all agree on.
>>
>> Thanks,
>> Andrew
>
> Would it be possible to do the opposite and have the docs pull from the
> txt document? I like the idea of having specific files that are easy to
> check as a developer or end user, and I think having a file that says
> "look at that other file" that contains everything GDB (and thus makes
> it harder to quickly find what you're looking for) would muddle that a
> little bit.
Not to mention the fact that $topsrcdir/SECURITY* is the first place
where people tend to look to report potential security issues. This is
similar in principle to "Reporting bugs"; the manual is usually the last
place one would look, although it makes sense to *also* put it in the
manual.
Thanks,
Sid
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RFC] Adding a SECURITY policy for GDB
2024-02-12 17:06 ` Siddhesh Poyarekar
@ 2024-02-14 15:03 ` Andrew Burgess
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Burgess @ 2024-02-14 15:03 UTC (permalink / raw)
To: Siddhesh Poyarekar, Guinevere Larsen, gdb-patches
Cc: Kevin Buettner, Simon Marchi, felix.willgerodt, Paul Koning
Siddhesh Poyarekar <siddhesh@redhat.com> writes:
> On 2024-02-12 11:43, Guinevere Larsen wrote:
>> On 08/12/2023 16:05, Andrew Burgess wrote:
>>> One last thing, while writing this, I did wonder if this text would be
>>> better moved into the GDB manual, and the gdb/SECURITY.txt document
>>> should just say "See the GDB manual", but I figure that's a problem for
>>> future me, for now I just need to find some words we can all agree on.
>>>
>>> Thanks,
>>> Andrew
>>
>> Would it be possible to do the opposite and have the docs pull from the
>> txt document? I like the idea of having specific files that are easy to
>> check as a developer or end user, and I think having a file that says
>> "look at that other file" that contains everything GDB (and thus makes
>> it harder to quickly find what you're looking for) would muddle that a
>> little bit.
>
> Not to mention the fact that $topsrcdir/SECURITY* is the first place
> where people tend to look to report potential security issues. This is
> similar in principle to "Reporting bugs"; the manual is usually the last
> place one would look, although it makes sense to *also* put it in the
> manual.
>
Which is why the SECURITY* file would redirect to the definitive text.
But this feels like a future problem. First we need to reach consensus
on some actual words.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [V3] [RFC] Adding a SECURITY policy for GDB
2024-02-04 15:36 ` [V3] " Andrew Burgess
@ 2024-02-18 13:55 ` Andrew Burgess
2024-03-27 11:00 ` [V4] " Andrew Burgess
0 siblings, 1 reply; 31+ messages in thread
From: Andrew Burgess @ 2024-02-18 13:55 UTC (permalink / raw)
To: gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
Thank you all for the continued feedback.
In V4 I have:
- Reordered some of the text. As I was adding/changing words I felt
the old order didn't make as much sense, so some of the paragraphs
have been shuffled around a little,
- Added some text about per-project/per-program configuration files
not being auto-loaded unless the user specifically allows them, and
mentioned that a bug which allowed such auto-loading without a user
command would be a security issues,
- Added some words to try and reflect the (current) reality which is
that the ELF/DWARF loaders are known/likely to contain bugs when
confronted with malformed input, which could result in undefined
behaviour, which could be a security issue. This effectively means
that, though we'd like to say it is safe to examine an untrusted
binary (so long as you don't execute it), in reality, it's not
really safe (currently) to do such a thing.
In some ways this is a return to the position from V1, against which
there was some push back. However, the new text is slightly
different. While V1 basically said "it's never safe to touch an
untrusted binary with GDB (outside of a sandboxed environment)", the
new text is trying to say "we'd like it to be safe to examine (but
not run) and untrusted binary, but we're not there yet".
This security document shouldn't be "final for all time", it should
be a living document, just like every other part of GDB. Hopefully,
in time, we might one day reach a position where we feel we can say
not only that we'd like such a use of GDB to be secure, but that it
actually _is_ secure (to the best of our knowledge).
All feedback welcome.
Thanks,
Andrew
---
GNU Debugger Security Policy
============================
Introduction
------------
The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
another program. This can be done by controlling the execution of
the program being debugged and allowing the user to inspect and
modify the state of the running program. Or GDB can be used to
analyse the program or a core file generated from the program
without needing to execute the program.
The program being debugged may be local i.e. on the system on which
GDB runs or remote, on a different system.
Policy Objectives
-----------------
The objective of this policy is define what the GDB project
considers a security bug and what is a non-security bug, and how
bugs can be reported.
Additionally this policy discusses areas of GDB in which there are
known bugs, how these might lead to security issues, and how this
risk can be mitigated.
Scope Of This Policy
--------------------
This policy covers all currently supported versions of GDB as
released from the official GDB website and covers gdb, gdbserver, as
well as gcore and gdb-add-index, which are packaged with each GDB
release. The official GDB website can be found here:
https://sourceware.org/gdb/
Remote debugging uses GDB to connect to a remote target. GDB sends
commands to the remote target which then controls the process being
debugged. The GDB project provides one remote target, gdbserver,
which is included with official GDB releases. Bugs within gdbserver
are in scope for this policy.
Other projects also implement remote targets to which GDB can
connect. Any bugs in these remote targets are out of scope for this
policy and should be reported to the relevant project. However, any
bugs in GDB caused by a misbehaving remote target, even when that
target is not gdbserver, are in scope for this policy.
What Is A Security Bug?
-----------------------
Any bugs in GDB or gdbserver that result in an unexpected 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.
Any bugs in GDB that result in execution of the program being
debugged without the user issuing a GDB command triggering execution
(either from the GDB command line, a GDB configuration file, or from
the GDB prompt) are considered security bugs.
GDB will check for and load multiple configuration files. When
initially started GDB can load user and system specific
configuration files, this is done unconditionally as it is assumed
these files are under control of the user and are always safe to
load.
GDB can also load per-project and per-program configuration files,
this is done when a program to debug is loaded into GDB. These
configuration files will only be loaded if the use has given GDB
permission to load these files. Any bug in GDB which allows
per-project or per-program configuration files to be loaded without
permission having been granted by the user is considered a security
bug.
When gdbserver is started, if it is passed a program on its command
line then that program will be started, but paused before executing
its first instruction.
Any bug in gdbserver which results in further execution of the
program being debugged without GDB first connecting to the target
and sending a command that is intended to trigger execution is a
security bug in gdbserver.
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed by
a user command, is considered a security bug, e.g. if loading a
program into GDB could trigger arbitrary code execution, then this
is a security issue.
The additional tools gcore and gdb-add-index are scripts that wrap
around GDB. Any issue in these tools that meet the above
definitions of a security bug, are considered a security bug.
What Is Not A Security Bug
--------------------------
In the context of local debugging, when GDB is used to execute a
program, the program runs with the same privileges as GDB itself.
Any issues that arise from running an untrusted program outside of a
secure environment are not security bugs in GDB. Any issues that
arise from running an untrusted program through GDB inside a secure
environment are only security bugs if GDB is required in order to
trigger the issue.
It is possible for a program to detect when it is run under GDB and
to change its behavior so that unwanted behavior may only appear
when a program is run under GDB. Any issues that arise due to an
untrusted program detecting GDB and changing its behaviour are not
security issues in GDB unless the issue also meet some other
definition of a security bug.
In the context of remote debugging, the program being debugged is
run with the same privileges as gdbserver. As with GDB in the local
debugging case, any issues that arise from running an untrusted
program outside of a secure environment are not security bugs in
gdbserver.
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.
Any issues that arise due to a failure to protect the connection
between GDB and a remote target are not security bugs in either GDB
or gdbserver.
Security Realities Of The GDB Project
-------------------------------------
Within this section, references to GDB should be read as meaning
GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
otherwise.
The most common use case for GDB is a developer trying to resolve
issues within a program that they have either written themselves, or
within a program that they trust not to be malicious. In this
situation we would say GDB is being used to debug trusted code.
There is no greater security risk from running the program to debug
through GDB than there is running the program directly. Additional
process isolation for the GDB process is only needed if additional
isolation would have been applied anyway when running the program to
debug.
In some cases a developer may be given a program from an untrusted
source and be asked to debug an issue. In this situation we would
say GDB is being used to debug untrusted code. In this case the
user should take all the precautions when running GDB that they
would normally take when running an untrusted program outside of
GDB, e.g. running within a secure, sandboxed environment.
When using GDB to examine, but not execute, an untrusted program
(with gdbserver, the program will be started, but paused at the
first instruction and not run further), there should be no security
risks, however the GDB maintainers don't currently believe that GDB
or gdbserver is reliable enough to ensure that there are no security
risks.
There are known bugs in GDB related to loading malformed executables
and parsing the debug information, a consequence of these bugs is
that a malicious program could trigger undefined behaviour in GDB,
which could be used to trigger arbitrary code execution.
Given these risks, the advice of the GDB project is that, when using
GDB with an untrusted binary, always do so in a secure, sandboxed
environment.
As there are already known bugs in GDB relating to undefined
behaviour triggered from malformed programs, further bugs in this
area should still be reported, but are unlikely to be given high
priority. Bugs in GDB that are triggered by well-formed programs
should also be reported, and are likely to be treated as higher
priority as these are more likely to impact normal use of GDB.
When using GDB and gdbserver to perform remote debug, the connection
between the two components is by design insecure. It is up to the
user to protect this connection, for example, by only starting
gdbserver within a secure network.
Reporting Non-Security Bugs
---------------------------
NOTE: All bugs reported in the GDB Bugzilla are public.
Non-security bugs, as well as any security bugs that pose limited
risk to users should be reported in GDB's bugzilla system. Bugs
reported in this way will be public. The bugzilla system can be
found here:
https://sourceware.org/bugzilla/
Reporting Security Bugs
-----------------------
In order to report a private security bug that is not immediately
made public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle such
bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is
likely that the team will ask to file a public bug because the issue
is sufficiently minor and does not warrant keeping details of the
bug private.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [V4] [RFC] Adding a SECURITY policy for GDB
2024-02-18 13:55 ` Andrew Burgess
@ 2024-03-27 11:00 ` Andrew Burgess
2024-04-08 11:01 ` [V5] " Andrew Burgess
0 siblings, 1 reply; 31+ messages in thread
From: Andrew Burgess @ 2024-03-27 11:00 UTC (permalink / raw)
To: gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
I realise I didn't tag my last update as V4.
I wonder if anyone has any thoughts on this latest iteration.
Andrew Burgess <aburgess@redhat.com> writes:
> Thank you all for the continued feedback.
>
> In V4 I have:
>
> - Reordered some of the text. As I was adding/changing words I felt
> the old order didn't make as much sense, so some of the paragraphs
> have been shuffled around a little,
>
> - Added some text about per-project/per-program configuration files
> not being auto-loaded unless the user specifically allows them, and
> mentioned that a bug which allowed such auto-loading without a user
> command would be a security issues,
>
> - Added some words to try and reflect the (current) reality which is
> that the ELF/DWARF loaders are known/likely to contain bugs when
> confronted with malformed input, which could result in undefined
> behaviour, which could be a security issue. This effectively means
> that, though we'd like to say it is safe to examine an untrusted
> binary (so long as you don't execute it), in reality, it's not
> really safe (currently) to do such a thing.
>
> In some ways this is a return to the position from V1, against which
> there was some push back. However, the new text is slightly
> different. While V1 basically said "it's never safe to touch an
> untrusted binary with GDB (outside of a sandboxed environment)", the
> new text is trying to say "we'd like it to be safe to examine (but
> not run) and untrusted binary, but we're not there yet".
>
> This security document shouldn't be "final for all time", it should
> be a living document, just like every other part of GDB. Hopefully,
> in time, we might one day reach a position where we feel we can say
> not only that we'd like such a use of GDB to be secure, but that it
> actually _is_ secure (to the best of our knowledge).
>
> All feedback welcome.
>
> Thanks,
> Andrew
---
GNU Debugger Security Policy
============================
Introduction
------------
The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
another program. This can be done by controlling the execution of
the program being debugged and allowing the user to inspect and
modify the state of the running program. Or GDB can be used to
analyse the program or a core file generated from the program
without needing to execute the program.
The program being debugged may be local i.e. on the system on which
GDB runs or remote, on a different system.
Policy Objectives
-----------------
The objective of this policy is define what the GDB project
considers a security bug and what is a non-security bug, and how
bugs can be reported.
Additionally this policy discusses areas of GDB in which there are
known bugs, how these might lead to security issues, and how this
risk can be mitigated.
Scope Of This Policy
--------------------
This policy covers all currently supported versions of GDB as
released from the official GDB website and covers gdb, gdbserver, as
well as gcore and gdb-add-index, which are packaged with each GDB
release. The official GDB website can be found here:
https://sourceware.org/gdb/
Remote debugging uses GDB to connect to a remote target. GDB sends
commands to the remote target which then controls the process being
debugged. The GDB project provides one remote target, gdbserver,
which is included with official GDB releases. Bugs within gdbserver
are in scope for this policy.
Other projects also implement remote targets to which GDB can
connect. Any bugs in these remote targets are out of scope for this
policy and should be reported to the relevant project. However, any
bugs in GDB caused by a misbehaving remote target, even when that
target is not gdbserver, are in scope for this policy.
What Is A Security Bug?
-----------------------
Any bugs in GDB or gdbserver that result in an unexpected 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.
Any bugs in GDB that result in execution of the program being
debugged without the user issuing a GDB command triggering execution
(either from the GDB command line, a GDB configuration file, or from
the GDB prompt) are considered security bugs.
GDB will check for and load multiple configuration files. When
initially started GDB can load user and system specific
configuration files, this is done unconditionally as it is assumed
these files are under control of the user and are always safe to
load.
GDB can also load per-project and per-program configuration files,
this is done when a program to debug is loaded into GDB. These
configuration files will only be loaded if the use has given GDB
permission to load these files. Any bug in GDB which allows
per-project or per-program configuration files to be loaded without
permission having been granted by the user is considered a security
bug.
When gdbserver is started, if it is passed a program on its command
line then that program will be started, but paused before executing
its first instruction.
Any bug in gdbserver which results in further execution of the
program being debugged without GDB first connecting to the target
and sending a command that is intended to trigger execution is a
security bug in gdbserver.
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed by
a user command, is considered a security bug, e.g. if loading a
program into GDB could trigger arbitrary code execution, then this
is a security issue.
The additional tools gcore and gdb-add-index are scripts that wrap
around GDB. Any issue in these tools that meet the above
definitions of a security bug, are considered a security bug.
What Is Not A Security Bug
--------------------------
In the context of local debugging, when GDB is used to execute a
program, the program runs with the same privileges as GDB itself.
Any issues that arise from running an untrusted program outside of a
secure environment are not security bugs in GDB. Any issues that
arise from running an untrusted program through GDB inside a secure
environment are only security bugs if GDB is required in order to
trigger the issue.
It is possible for a program to detect when it is run under GDB and
to change its behavior so that unwanted behavior may only appear
when a program is run under GDB. Any issues that arise due to an
untrusted program detecting GDB and changing its behaviour are not
security issues in GDB unless the issue also meet some other
definition of a security bug.
In the context of remote debugging, the program being debugged is
run with the same privileges as gdbserver. As with GDB in the local
debugging case, any issues that arise from running an untrusted
program outside of a secure environment are not security bugs in
gdbserver.
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.
Any issues that arise due to a failure to protect the connection
between GDB and a remote target are not security bugs in either GDB
or gdbserver.
Security Realities Of The GDB Project
-------------------------------------
Within this section, references to GDB should be read as meaning
GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
otherwise.
The most common use case for GDB is a developer trying to resolve
issues within a program that they have either written themselves, or
within a program that they trust not to be malicious. In this
situation we would say GDB is being used to debug trusted code.
There is no greater security risk from running the program to debug
through GDB than there is running the program directly. Additional
process isolation for the GDB process is only needed if additional
isolation would have been applied anyway when running the program to
debug.
In some cases a developer may be given a program from an untrusted
source and be asked to debug an issue. In this situation we would
say GDB is being used to debug untrusted code. In this case the
user should take all the precautions when running GDB that they
would normally take when running an untrusted program outside of
GDB, e.g. running within a secure, sandboxed environment.
When using GDB to examine, but not execute, an untrusted program
(with gdbserver, the program will be started, but paused at the
first instruction and not run further), there should be no security
risks, however the GDB maintainers don't currently believe that GDB
or gdbserver is reliable enough to ensure that there are no security
risks.
There are known bugs in GDB related to loading malformed executables
and parsing the debug information, a consequence of these bugs is
that a malicious program could trigger undefined behaviour in GDB,
which could be used to trigger arbitrary code execution.
Given these risks, the advice of the GDB project is that, when using
GDB with an untrusted binary, always do so in a secure, sandboxed
environment.
As there are already known bugs in GDB relating to undefined
behaviour triggered from malformed programs, further bugs in this
area should still be reported, but are unlikely to be given high
priority. Bugs in GDB that are triggered by well-formed programs
should also be reported, and are likely to be treated as higher
priority as these are more likely to impact normal use of GDB.
When using GDB and gdbserver to perform remote debug, the connection
between the two components is by design insecure. It is up to the
user to protect this connection, for example, by only starting
gdbserver within a secure network.
Reporting Non-Security Bugs
---------------------------
NOTE: All bugs reported in the GDB Bugzilla are public.
Non-security bugs, as well as any security bugs that pose limited
risk to users should be reported in GDB's bugzilla system. Bugs
reported in this way will be public. The bugzilla system can be
found here:
https://sourceware.org/bugzilla/
Reporting Security Bugs
-----------------------
In order to report a private security bug that is not immediately
made public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle such
bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is
likely that the team will ask to file a public bug because the issue
is sufficiently minor and does not warrant keeping details of the
bug private.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [V5] [RFC] Adding a SECURITY policy for GDB
2024-03-27 11:00 ` [V4] " Andrew Burgess
@ 2024-04-08 11:01 ` Andrew Burgess
2024-04-09 20:30 ` Tom Tromey
2024-04-10 10:22 ` Willgerodt, Felix
0 siblings, 2 replies; 31+ messages in thread
From: Andrew Burgess @ 2024-04-08 11:01 UTC (permalink / raw)
To: gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
In V5:
- Fixed a couple of minor typos that were pointed out by someone
off-list.
Any additional feedback would be great.
If there's no feedback, how would people feel about me merging this? So
long as the content is not objectionable then minor corrections or
additions can be made via the normal patch process in the future.
I know I mentioned adding this text to the GDB manual previously, but I
recall someone objected to that at the time. Right now I'm thinking to
add this as a standalone document, and possibly merge it into the manual
later in the year.
Thoughts?
Thanks,
Andrew
---
GNU Debugger Security Policy
============================
Introduction
------------
The GNU Debugger (GDB) is a tool for diagnosing issues "inside"
another program. This can be done by controlling the execution of
the program being debugged and allowing the user to inspect and
modify the state of the running program. Or GDB can be used to
analyse the program or a core file generated from the program
without needing to execute the program.
The program being debugged may be local i.e. on the system on which
GDB runs or remote, on a different system.
Policy Objectives
-----------------
The objective of this policy is define what the GDB project
considers a security bug and what is a non-security bug, and how
bugs can be reported.
Additionally this policy discusses areas of GDB in which there are
known bugs, how these might lead to security issues, and how this
risk can be mitigated.
Scope Of This Policy
--------------------
This policy covers all currently supported versions of GDB as
released from the official GDB website and covers gdb, gdbserver, as
well as gcore and gdb-add-index, which are packaged with each GDB
release. The official GDB website can be found here:
https://sourceware.org/gdb/
Remote debugging uses GDB to connect to a remote target. GDB sends
commands to the remote target which then controls the process being
debugged. The GDB project provides one remote target, gdbserver,
which is included with official GDB releases. Bugs within gdbserver
are in scope for this policy.
Other projects also implement remote targets to which GDB can
connect. Any bugs in these remote targets are out of scope for this
policy and should be reported to the relevant project. However, any
bugs in GDB caused by a misbehaving remote target, even when that
target is not gdbserver, are in scope for this policy.
What Is A Security Bug?
-----------------------
Any bugs in GDB or gdbserver that result in an unexpected 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.
Any bugs in GDB that result in execution of the program being
debugged without the user issuing a GDB command triggering execution
(either from the GDB command line, a GDB configuration file, or from
the GDB prompt) are considered security bugs.
GDB will check for and load multiple configuration files. When
initially started GDB can load user- and system-specific
configuration files, this is done unconditionally as it is assumed
these files are under control of the user and are always safe to
load.
GDB can also load per-project and per-program configuration files,
this is done when a program to debug is loaded into GDB. These
configuration files will only be loaded if the user has given GDB
permission to load these files. Any bug in GDB which allows
per-project or per-program configuration files to be loaded without
permission having been granted by the user is considered a security
bug.
When gdbserver is started, if it is passed a program on its command
line then that program will be started, but paused before executing
its first instruction.
Any bug in gdbserver which results in further execution of the
program being debugged without GDB first connecting to the target
and sending a command that is intended to trigger execution is a
security bug in gdbserver.
Any bug in GDB or gdbserver that can trigger arbitrary code
execution without the program being debugged having been executed by
a user command, is considered a security bug, e.g. if loading a
program into GDB could trigger arbitrary code execution, then this
is a security issue.
The additional tools gcore and gdb-add-index are scripts that wrap
around GDB. Any issue in these tools that meet the above
definitions of a security bug, are considered a security bug.
What Is Not A Security Bug
--------------------------
In the context of local debugging, when GDB is used to execute a
program, the program runs with the same privileges as GDB itself.
Any issues that arise from running an untrusted program outside of a
secure environment are not security bugs in GDB. Any issues that
arise from running an untrusted program through GDB inside a secure
environment are only security bugs if GDB is required in order to
trigger the issue.
It is possible for a program to detect when it is run under GDB and
to change its behavior so that unwanted behavior may only appear
when a program is run under GDB. Any issues that arise due to an
untrusted program detecting GDB and changing its behaviour are not
security issues in GDB unless the issue also meet some other
definition of a security bug.
In the context of remote debugging, the program being debugged is
run with the same privileges as gdbserver. As with GDB in the local
debugging case, any issues that arise from running an untrusted
program outside of a secure environment are not security bugs in
gdbserver.
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.
Any issues that arise due to a failure to protect the connection
between GDB and a remote target are not security bugs in either GDB
or gdbserver.
Security Realities Of The GDB Project
-------------------------------------
Within this section, references to GDB should be read as meaning
GDB, gdbserver, gcore, or gdb-add-index, unless specifically stated
otherwise.
The most common use case for GDB is a developer trying to resolve
issues within a program that they have either written themselves, or
within a program that they trust not to be malicious. In this
situation we would say GDB is being used to debug trusted code.
There is no greater security risk from running the program to debug
through GDB than there is running the program directly. Additional
process isolation for the GDB process is only needed if additional
isolation would have been applied anyway when running the program to
debug.
In some cases a developer may be given a program from an untrusted
source and be asked to debug an issue. In this situation we would
say GDB is being used to debug untrusted code. In this case the
user should take all the precautions when running GDB that they
would normally take when running an untrusted program outside of
GDB, e.g. running within a secure, sandboxed environment.
When using GDB to examine, but not execute, an untrusted program
(with gdbserver, the program will be started, but paused at the
first instruction and not run further), there should be no security
risks, however the GDB maintainers don't currently believe that GDB
or gdbserver is reliable enough to ensure that there are no security
risks.
There are known bugs in GDB related to loading malformed executables
and parsing the debug information, a consequence of these bugs is
that a malicious program could trigger undefined behaviour in GDB,
which could be used to trigger arbitrary code execution.
Given these risks, the advice of the GDB project is that, when using
GDB with an untrusted binary, always do so in a secure, sandboxed
environment.
As there are already known bugs in GDB relating to undefined
behaviour triggered from malformed programs, further bugs in this
area should still be reported, but are unlikely to be given high
priority. Bugs in GDB that are triggered by well-formed programs
should also be reported, and are likely to be treated as higher
priority as these are more likely to impact normal use of GDB.
When using GDB and gdbserver to perform remote debug, the connection
between the two components is by design insecure. It is up to the
user to protect this connection, for example, by only starting
gdbserver within a secure network.
Reporting Non-Security Bugs
---------------------------
NOTE: All bugs reported in the GDB Bugzilla are public.
Non-security bugs, as well as any security bugs that pose limited
risk to users should be reported in GDB's bugzilla system. Bugs
reported in this way will be public. The bugzilla system can be
found here:
https://sourceware.org/bugzilla/
Reporting Security Bugs
-----------------------
In order to report a private security bug that is not immediately
made public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle such
bugs:
Red Hat: secalert@redhat.com
SUSE: security@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is
likely that the team will ask to file a public bug because the issue
is sufficiently minor and does not warrant keeping details of the
bug private.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [V5] [RFC] Adding a SECURITY policy for GDB
2024-04-08 11:01 ` [V5] " Andrew Burgess
@ 2024-04-09 20:30 ` Tom Tromey
2024-04-10 10:22 ` Willgerodt, Felix
1 sibling, 0 replies; 31+ messages in thread
From: Tom Tromey @ 2024-04-09 20:30 UTC (permalink / raw)
To: Andrew Burgess
Cc: gdb-patches, Siddhesh Poyarekar, Kevin Buettner, Simon Marchi,
felix.willgerodt, Paul Koning
>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
Andrew> If there's no feedback, how would people feel about me merging this? So
Andrew> long as the content is not objectionable then minor corrections or
Andrew> additions can be made via the normal patch process in the future.
I am in favor of merging it. I re-read it and I agree with what it
says.
Approved-By: Tom Tromey <tom@tromey.com>
Andrew> I know I mentioned adding this text to the GDB manual previously, but I
Andrew> recall someone objected to that at the time. Right now I'm thinking to
Andrew> add this as a standalone document, and possibly merge it into the manual
Andrew> later in the year.
I'm comfortable with this approach.
thank you,
Tom
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [V5] [RFC] Adding a SECURITY policy for GDB
2024-04-08 11:01 ` [V5] " Andrew Burgess
2024-04-09 20:30 ` Tom Tromey
@ 2024-04-10 10:22 ` Willgerodt, Felix
2024-04-26 15:44 ` Andrew Burgess
1 sibling, 1 reply; 31+ messages in thread
From: Willgerodt, Felix @ 2024-04-10 10:22 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi, Paul Koning
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Montag, 8. April 2024 13:02
> To: gdb-patches@sourceware.org
> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>; Kevin Buettner
> <kevinb@redhat.com>; Simon Marchi <simark@simark.ca>; Willgerodt, Felix
> <felix.willgerodt@intel.com>; Paul Koning <paulkoning@comcast.net>
> Subject: [V5] [RFC] Adding a SECURITY policy for GDB
>
>
> In V5:
>
> - Fixed a couple of minor typos that were pointed out by someone
> off-list.
>
> Any additional feedback would be great.
>
> If there's no feedback, how would people feel about me merging this? So
> long as the content is not objectionable then minor corrections or
> additions can be made via the normal patch process in the future.
>
> I know I mentioned adding this text to the GDB manual previously, but I
> recall someone objected to that at the time. Right now I'm thinking to
> add this as a standalone document, and possibly merge it into the manual
> later in the year.
>
> Thoughts?
>
> Thanks,
> Andrew
I find the text reasonable and am in favour of merging this and evolving it
from there if needed.
Having a SECURITY file in repos seems common practice nowadays.
Though having it in the manual also has its advantages, as there it is potentially
easier to find for users. Maybe we could reference the docs from the
SECURITY file? But I am ok with either places, having it at all is most
important.
Regards,
Felix
> Reporting Security Bugs
> -----------------------
>
> In order to report a private security bug that is not immediately
> made public, please contact one of the downstream distributions with
> security teams. The following teams have volunteered to handle such
> bugs:
>
> Red Hat: secalert@redhat.com
> SUSE: security@suse.de
>
In case you wanted to align the two email addresses, they aren't quite
aligned.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [V5] [RFC] Adding a SECURITY policy for GDB
2024-04-10 10:22 ` Willgerodt, Felix
@ 2024-04-26 15:44 ` Andrew Burgess
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Burgess @ 2024-04-26 15:44 UTC (permalink / raw)
To: Willgerodt, Felix, gdb-patches
Cc: Siddhesh Poyarekar, Kevin Buettner, Simon Marchi, Paul Koning
"Willgerodt, Felix" <felix.willgerodt@intel.com> writes:
>> -----Original Message-----
>> From: Andrew Burgess <aburgess@redhat.com>
>> Sent: Montag, 8. April 2024 13:02
>> To: gdb-patches@sourceware.org
>> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>; Kevin Buettner
>> <kevinb@redhat.com>; Simon Marchi <simark@simark.ca>; Willgerodt, Felix
>> <felix.willgerodt@intel.com>; Paul Koning <paulkoning@comcast.net>
>> Subject: [V5] [RFC] Adding a SECURITY policy for GDB
>>
>>
>> In V5:
>>
>> - Fixed a couple of minor typos that were pointed out by someone
>> off-list.
>>
>> Any additional feedback would be great.
>>
>> If there's no feedback, how would people feel about me merging this? So
>> long as the content is not objectionable then minor corrections or
>> additions can be made via the normal patch process in the future.
>>
>> I know I mentioned adding this text to the GDB manual previously, but I
>> recall someone objected to that at the time. Right now I'm thinking to
>> add this as a standalone document, and possibly merge it into the manual
>> later in the year.
>>
>> Thoughts?
>>
>> Thanks,
>> Andrew
>
> I find the text reasonable and am in favour of merging this and evolving it
> from there if needed.
>
> Having a SECURITY file in repos seems common practice nowadays.
> Though having it in the manual also has its advantages, as there it is potentially
> easier to find for users. Maybe we could reference the docs from the
> SECURITY file? But I am ok with either places, having it at all is most
> important.
Hi Felix,
I'm also think having this text in the manual might be a good thing.
When I mentioned this idea earlier in the thread there was some
disagreement though, so for now I've merged this as a text file; I'm
keen to get something in to the tree, then I can potentially move it
later on.
I'll work up a patch to move this into the manual and post it probably
after 15.1 branches.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2024-04-26 15:44 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-06 13:26 [RFC] Adding a SECURITY policy for GDB Andrew Burgess
2023-11-06 18:55 ` Kevin Buettner
2023-11-06 19:34 ` Simon Marchi
2023-11-06 20:09 ` Siddhesh Poyarekar
2023-11-06 20:15 ` Simon Marchi
2023-11-07 12:17 ` Siddhesh Poyarekar
2023-11-07 14:22 ` Simon Marchi
2023-11-09 14:35 ` Willgerodt, Felix
2023-11-16 17:19 ` Andrew Burgess
2023-11-16 17:27 ` Paul Koning
2023-11-16 21:35 ` Siddhesh Poyarekar
2023-12-08 15:05 ` Andrew Burgess
2023-12-09 10:55 ` Eli Zaretskii
2024-02-04 15:32 ` Andrew Burgess
2024-02-04 17:18 ` Eli Zaretskii
2024-02-04 17:43 ` Andreas Schwab
2024-02-04 18:56 ` Eli Zaretskii
2024-02-05 11:06 ` Andrew Burgess
2023-12-12 7:27 ` Willgerodt, Felix
2024-02-04 15:36 ` [V3] " Andrew Burgess
2024-02-18 13:55 ` Andrew Burgess
2024-03-27 11:00 ` [V4] " Andrew Burgess
2024-04-08 11:01 ` [V5] " Andrew Burgess
2024-04-09 20:30 ` Tom Tromey
2024-04-10 10:22 ` Willgerodt, Felix
2024-04-26 15:44 ` Andrew Burgess
2024-02-05 21:01 ` Tom Tromey
2024-02-09 15:59 ` Andrew Burgess
2024-02-12 16:43 ` Guinevere Larsen
2024-02-12 17:06 ` Siddhesh Poyarekar
2024-02-14 15:03 ` Andrew Burgess
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).