1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
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, sometimes
referred to as extension scripts or plugins. When initially started
GDB can load user-specific and/or 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. All of these files
are treated as trusted input, meaning GDB makes no attempt to sanitize
commands and has no sandboxing or other protections against effects of
commands run by any automatically loaded file. It is up to the user to
audit files against documentation provided by the relevant projects to
protect against malicious commands. If executing commands provided by
the GDB project generates undocumented side effects, this is a bug. For
that bug to be considered a security bug, it must meet other definitions
of security bugs outlined in this document.
GDB can also load per-project and/or per-program configuration files
when a program is loaded for debugging. Such files will only be loaded
if the user has given GDB permission to load them. 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.
GDB is not meant to be offered as a service (that is, offered
over an insecure connection to non-local users), and so denial of
service attacks targeting GDB itself, or other bugs that target
this use case, are not considered a security bug.
By the same token, simply triggering an internal error in GDB is not
considered a security bug, since GDB has detected an issue and
handled it in a non-exploitable manner. If it can be demonstrated
that some bug other than the internal error happens, this other bug
should be evaluated independently of the error, and may be a security
bug if it fits some of the definitions in this document.
GDB provides 3 different turing complete languages, Guile, Python
and direct access to the shell. Making use of these languages can
have unknown effects, including outside of the GDB process. Such
effects will only be considered security bugs if they fit some of the
definitions in this document and the effect can only be reproduced
when executed in the GDB environment.
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.
|
