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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
|
#use wml::debian::template title="Debian security FAQ"
#include "$(ENGLISHDIR)/security/faq.inc"
# $Id$
<maketoc>
<toc-add-entry name=buthow>I received a DSA via debian-security-announce, how can I upgrade the vulnerable packages?</toc-add-entry>
<p>A: As the DSA mail says, you should upgrade the packages affected by the
announced vulnerability. You can do this by just upgrading (after
updating the list of available packages with <tt>apt-get update</tt>)
every package in your system with <tt>apt-get upgrade</tt> or by
upgrading just a particular package, with <tt>apt-get install
<i>package</i></tt>.</p>
<p>The announcement mail mentions the source package in which the vulnerability
was present. Therefore, you should update all the binary packages from
that source package. To check the binary packages to update, visit
<tt>https://packages.debian.org/src:<i>source-package-name</i></tt> and
click on <i>[show ... binary packages]</i> for the distribution you
are updating.</p>
<p>It may also be necessary to restart a service or a running process. The
command <a href="https://manpages.debian.org/checkrestart"><tt>checkrestart</tt></a>
included in the package
<a href="https://packages.debian.org/debian-goodies">debian-goodies</a>
might help to find which ones.</p>
<toc-add-entry name=signature>The signature on your advisories does not verify correctly!</toc-add-entry>
<p>A: This is most likely a problem on your end. The
<a href="https://lists.debian.org/debian-security-announce/">\
debian-security-announce</a>
list has a filter that only allows messages with a correct signature
from one of the security team members to be posted.</p>
<p>Most likely some piece of mail software on your end slightly changes
the message that breaks the signature. Make sure your software does
not do any MIME encoding or decoding, or tab/space conversions.</p>
<p>Known culprits are fetchmail (with the mimedecode option enabled),
formail (from procmail 3.14 only) and evolution.</p>
<toc-add-entry name="handling">How is security handled in Debian?</toc-add-entry>
<p>A: Once the security team receives a notification of an incident,
one or more members review it and consider its impact on the stable
release of Debian (i.e. if it's vulnerable or not).
If our system is vulnerable, we work on a fix for the
problem. The package maintainer is contacted as well, if they didn't
contact the security team already. Finally, the fix is tested and
new packages are prepared, which are then compiled on all stable
architectures and uploaded afterwards. After all of that is done,
an advisory is published.</p>
<toc-add-entry name=oldversion>Why are you fiddling with an old version of that package?</toc-add-entry>
<p>The most important guideline when making a new package that fixes a
security problem is to make as few changes as possible. Our users and
developers are relying on the exact behaviour of a release once it is made,
so any change we make can possibly break someone's system. This is
especially true in case of libraries: make sure you never change the
Application Program Interface (API) or Application Binary Interface (ABI),
no matter how small the change is.</p>
<p>This means that moving to a new upstream version is not a good solution,
instead the relevant changes should be backported. Generally upstream
maintainers are willing to help if needed, if not the Debian security team
might be able to help.</p>
<p>In some cases it is not possible to backport a security fix, for example
when large amounts of source code need to be modified or rewritten. If that
happens it might be necessary to move to a new upstream version, but this
has to be coordinated with the security team beforehand.</p>
<toc-add-entry name=version>The version number for a package indicates that I am still running
a vulnerable version!</toc-add-entry>
<p>A: Instead of upgrading to a new release we backport security fixes to
the version that was shipped in the stable release. The reason we do
this is to make sure that a release changes as little as possible
so things will not change or break unexpectedly as a result of a
security fix. You can check if you are running a secure version of
a package by looking at the package changelog, or comparing its
exact version number with the version indicated in the Debian
Security Advisory.</p>
<toc-add-entry name=archismissing>I received an advisory, but the build for one
processor architecture seems to be missing.</toc-add-entry>
<p>A: Generally the Security Team releases an advisory with builds of the updated
packages for all architectures that Debian supports. However, some architectures
are slower than others and it may happen that builds for most architectures
are ready while some are still missing. These smaller archs represent a small
fraction of our user base. Depending on the urgency of the issue
we may decide to release the advisory forthwith. The missing builds will be
installed as soon as they come available, but no further notice of this will
be given. Of course we will never release an advisory where the i386 or amd64
builds are not present.</p>
<toc-add-entry name=unstable>How is security handled for <tt>unstable</tt>?</toc-add-entry>
<p>A: Security for unstable is primarily handled by package maintainers, not
by the Debian Security Team. Although the security team may upload
high-urgency security-only fixes when maintainers are noticed to be
inactive, support for stable will always have priority.
If you want to have a secure (and stable) server you are strongly encouraged
to stay with stable.</p>
<toc-add-entry name=testing>How is security handled for <tt>testing</tt>?</toc-add-entry>
<p>A: Security for testing benefits from the security efforts of the entire
project for unstable. However, there is a minimum two-day migration delay,
and sometimes security fixes can be held up by transitions. The Security
Team helps to move along those transitions holding back important
security uploads, but this is not always possible and delays may occur.
Especially in the months after a new stable release, when many new versions
are uploaded to unstable, security fixes for testing may lag behind.
If you want to have a secure (and stable) server you are strongly
encouraged to stay with stable.</p>
<toc-add-entry name=contrib>How is security handled for <tt>contrib</tt>,
<tt>non-free</tt> and <tt>non-free-firmware</tt>?</toc-add-entry>
<p>A: The short answer is: it's not. Contrib, non-free and non-free-firmware aren't official
parts of the Debian Distribution and are not released, and thus not
supported by the security team. Some non-free packages are distributed
without source or without a license allowing the distribution of modified
versions. In those cases no security fixes can be made at all. If it
is possible to fix the problem, and the package maintainer or someone else
provides correct updated packages, then the security team will generally
process them and release an advisory.</p>
<toc-add-entry name=sidversionisold>The advisory says unstable is fixed in
version 1.2.3-1, but unstable has 1.2.5-1, what's up?</toc-add-entry>
<p>A: We try to list the first version in unstable that fixed the problem.
Sometimes the maintainer has uploaded even newer versions in the meantime.
Compare the version in unstable with the version we indicate. If it's the
same or higher, you should be safe from this vulnerability. If you want to
be sure, you can check the package changelog with <tt>apt-get changelog
package-name</tt> and search for the entry announcing the fix.</p>
<toc-add-entry name=mirror>Why are there no official mirrors for security.debian.org?</toc-add-entry>
<p>A: Actually, there are. There are several official mirrors, implemented
through DNS aliases. The purpose of security.debian.org is to make security
updates available as quickly and easily as possible.</p>
<p>Encouraging the use of unofficial mirrors would add extra complexity
that is usually not needed and that can cause frustration if these
mirrors are not kept up to date.</p>
<toc-add-entry name=missing>I've seen DSA 100 and DSA 102, now where is DSA 101?</toc-add-entry>
<p>A: Several vendors (mostly of GNU/Linux, but also of BSD
derivatives) coordinate security advisories for some incidents and
agree to a particular timeline so that all vendors are able to
release an advisory at the same time. This was decided in order to
not discriminate some vendors that need more time (e.g. when the
vendor has to pass packages through lengthy QA tests or has to
support several architectures or binary distributions). Our own
security team also prepares advisories in advance. Every now and
then, other security issues have to be dealt with before the parked
advisory could be released, and hence temporarily leaving out one or
more advisories by number.
</p>
<toc-add-entry name=contact>How can I reach the security team?</toc-add-entry>
<p>A: Security information can be sent to security@debian.org or
team@security.debian.org, both of which are read by the members of
the security team.
</p>
<p>If desired, email can be encrypted with the Debian Security
Contact key (key ID <a
href="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0d59d2b15144766a14d241c66baf400b05c3e651">\
0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>). For the PGP/GPG keys of individual team members, please
refer to the <a href="https://keyring.debian.org/">keyring.debian.org</a>
keyserver.</p>
<toc-add-entry name=discover>I guess I found a security problem, what should I do?</toc-add-entry>
<p>A: If you learn about a security problem, either in one of your own
packages or in someone else's please always contact the security team. If
the Debian security team confirms the vulnerability and other vendors are
likely to be vulnerable as well, they usually contact other vendors as
well. If the vulnerability is not yet public they will try to coordinate
security advisories with the other vendors, so all major distributions are
in sync.</p>
<p>If the vulnerability is already publicly known, be sure to file a bug
report in the Debian BTS, and tag it <q>security</q>.</p>
<p>If you are a Debian maintainer, <a href="#care">see below</a>.</p>
<toc-add-entry name=care>What am I supposed to do with a security problem in one of
my packages?</toc-add-entry>
<p>A: If you learn of a security problem, either in your package or
someone else's please always contact the security team via email at
team@security.debian.org. They keep track
of outstanding security problems, can help maintainers with
security problems or fix problems on their own, are responsible for
sending out security advisories and maintaining
security.debian.org.</p>
<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
Developer's Reference</a> has complete instructions on what to do.</p>
<p>It's particularly important that you don't upload to any other
distribution other than unstable without prior agreement by the
security team, because bypassing them will cause confusion and more
work.</p>
<toc-add-entry name=enofile>I tried to download a package listed in one of the security
advisories, but I got a `file not found' error.</toc-add-entry>
<p>A: Whenever a newer bugfix supersedes an older package on
security.debian.org, chances are high that the old package will be
removed by the time the new one gets installed. Hence, you'll get
this `file not found' error. We don't want to distribute packages
with known security bugs longer than absolutely necessary.</p>
<p>Please use the packages from the latest security advisories, which are
distributed through the <a
href="https://lists.debian.org/debian-security-announce/">\
debian-security-announce</a> mailing list. It's best to simply run
<code>apt-get update</code> before upgrading the package.</p>
<toc-add-entry name=upload>I've got a bugfix, can I upload to security.debian.org directly?</toc-add-entry>
<p>A: No, you can't. The archive at security.debian.org is maintained
by the security team, who have to approve all packages. You should
instead send patches or proper source packages to the security team
via team@security.debian.org. They will be
reviewed by the security team and eventually uploaded, either with
or without modifications.</p>
<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
Developer's Reference</a> has complete instructions on what to do.</p>
<toc-add-entry name=ppu>I've got a bugfix, can I upload to proposed-updates instead?</toc-add-entry>
<p>A: Technically speaking, you can. However, you should not do this,
since this interferes badly with the work of the security team.
Packages from security.debian.org will be copied into the
proposed-updates directory automatically. If a package with the
same or a higher version number is already installed into the
archive, the security update will be rejected by the archive
system. That way, the stable distribution will end up without a
security update for this package instead, unless the <q>wrong</q>
packages in the proposed-updates directory were rejected. Please contact the
security team instead and include all details of the vulnerability
and attach the source files (i.e. diff.gz and dsc files) to your mail.</p>
<p>The <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
Developer's Reference</a> has complete instructions on what to do.</p>
<toc-add-entry name=SecurityUploadQueue>I'm pretty sure my packages are fine,
how can I upload them?</toc-add-entry>
<p>A: If you are very sure that your packages don't break anything, that the
version is sane (i.e. greater than the version in stable and less than the
version in testing/unstable), that you didn't change the behaviour of the
package, despite the corresponding security problem, that you compiled it
for the correct distribution (that is <code>oldstable-security</code> or
<code>stable-security</code>), that the package contains the original
source if the package is new on security.debian.org, that you can confirm
the patch against the most recent version is clean and only touches the
corresponding security problem (check with <code>interdiff -z</code> and
both <code>.diff.gz</code> files), that you have proofread the patch at
least thrice, and that <code>debdiff</code> doesn't display any changes,
you may upload the files into the incoming directory
<code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code> on the
security.debian.org directly. Please send a notification with all details
and links to team@security.debian.org as well.</p>
<toc-add-entry name=help>How can I help with security?</toc-add-entry>
<p>A: Please review each problem before reporting it to
security@debian.org. If you are able to provide patches, that
would speed up the process. Do not simply forward bugtraq mails,
because we already receive them — but do provide us with
additional information about things reported on bugtraq.</p>
<p>A good way to get started with security work is helping
out on the Debian Security Tracker (<a
href="https://security-tracker.debian.org/tracker/data/report">instructions</a>).</p>
<toc-add-entry name=proposed-updates>What is the scope of proposed-updates?</toc-add-entry>
<p>A: This directory contains packages which are proposed to enter the
next revision of Debian stable. Whenever packages are uploaded by
a maintainer for the stable distribution, they end up in the
proposed-updates directory. Since stable is meant to be stable, no
automatic updates are made. The security team will upload fixed
packages mentioned in their advisories to stable, however they will
be placed in proposed-updates first. Every couple of months the
Stable Release Manager checks the list of packages in
proposed-updates and discusses whether a package is suited for
stable or not. This is compiled into another revision of stable
(e.g. 2.2r3 or 2.2r4). Packages that don't fit will probably be
rejected and dropped from proposed-updates as well.
</p>
<p>Note that the packages uploaded by maintainers (not by the security team)
in the proposed-updates/ directory are not supported by the security
team.</p>
<toc-add-entry name=composing>How is the security team composed?</toc-add-entry>
<p>A: The Debian security team consists of
<a href="../intro/organization#security">several officers and secretaries</a>.
The security team itself appoints people to join the team.</p>
<toc-add-entry name=lifespan>How long will security updates be provided?</toc-add-entry>
<p>A: The security team will support a stable distribution for
three years after its release. It is not possible to support three
distributions; supporting two simultaneously is already difficult
enough.
</p>
<toc-add-entry name=check>How can I check the integrity of packages?</toc-add-entry>
<p>A: This process involve checking the Release file signature against
the <a href="https://ftp-master.debian.org/keys.html">\
public key</a> used for the archive. The Release file contains the
checksums of Packages and Sources files, which contain
checksums of binary and source packages. Detailed instruction on how
to check packages integrity can be found in the <a
href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
Debian Securing Manual</a>.</p>
<toc-add-entry name=break>What to do if a random package breaks after a security update?</toc-add-entry>
<p>A: First of all, you should figure out why the package breaks and
how it is connected to the security update, then contact the
security team if it is serious or the stable release manager if it
is less serious. We're talking about random packages that break
after a security update of a different package. If you can't
figure out what's going wrong but have a correction, talk to the
security team as well. You may be redirected to the stable release
manager though.</p>
<toc-add-entry name=cvewhat>What is a CVE identifier?</toc-add-entry>
<p>A: The Common Vulnerabilities and Exposures project assignes
unique names, called CVE identifiers, to specific security
vulnerabilities, to make it easier to uniquely refer to a specific
issue. More information can be found at <a
href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
Wikipedia</a>.</p>
<toc-add-entry name=cvedsa>Does Debian issue a DSA for every CVE id?</toc-add-entry>
<p>A: The Debian security team keeps track of every issued CVE identifier,
connect it to the relevant Debian package and assess its impact in a
Debian context - the fact that something is assigned a CVE id does not
necessarily imply that the issue is a serious threat to a Debian system.
This information is tracked in the
<a href="https://security-tracker.debian.org">Debian Security Tracker</a>
and for the issues that are considered serious a Debian Security Advisory
will be issued.</p>
<p>Low-impact issues not qualifying for a DSA can be fixed in the next
release of Debian, in a point release of the current stable or oldstable
distributions, or are included in a DSA when that is being issued for a
more serious vulnerability.</p>
<toc-add-entry name=cveget>Can Debian assign CVE identifiers?</toc-add-entry>
<p>A: Debian is a CVE Numbering Authority and can assign ids, but per
CVE policy only to yet-undisclosed issues. If you have an undisclosed
security vulnerability for software in Debian and would like to get an
identifier for it, contact the Debian Security Team. For cases where the
vulnerability is already public, we advise to follow the procedure
detailed in the <a
href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
CVE OpenSource Request HOWTO</a>.</p>
<toc-add-entry name=disclosure-policy>Does Debian have a vulnerability disclosure policy?</toc-add-entry>
<p>A: Debian has published a <a href="disclosure-policy">vulnerability
disclosure policy</a> as part of its participation in the CVE
program.
<toc-add-entry name=cve-severity-assessment>Our vulnerability management tool
has shown that the following issues are open (list of CVEs with random CVSS
scores). When are those going to be fixed?</toc-add-entry>
<p>A: Debian does not provide CVSS scores and doesn't use CVSS scores from
external sources when triaging security issues.</p>
<p>You can check the state of every single CVE ID in the Debian Security Tracker by accessing
it by <a href="https://security-tracker.debian.org/tracker/CVE-ID">ID</a>.</p>
<p>The "Notes" section will contain additional information, e.g. that a security issue doesn't
warrant a Debian security update, but might get fixed in a subsequent point release.</p>
<p>A list of packages for which a Security update is planned can be found at the
<a href="https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dsa-needed.txt">\
dsa-needed list</a>.</p>
<p>If you find an error in triage data, you're very welcome to report it. The Debian Security Team will
however not generally react to requests asking for more specific information, you should instead contact
the vendor of your vulnerability management tool, after all they are the ones who alerted you about a
security issue and not Debian.</p>
<h1>Deprecated Debian security FAQ</h1>
<toc-add-entry name=localremote>What does <q>local (remote)</q> mean?</toc-add-entry>
<p><b>The field <i>Problem type</i> in DSA mails is not used since April 2014.</b><br/>
A: Some advisories cover vulnerabilities that cannot be identified
with the classic scheme of local and remote exploitability. Some
vulnerabilities cannot be exploited from remote, i.e. don't
correspond to a daemon listening to a network port. If they can be
exploited by special files that could be provided via the network
while the vulnerable service is not permanently connected with the
network, we write <q>local (remote)</q> in such cases.</p>
<p>Such vulnerabilities are somewhat between local and remote
vulnerabilities and often cover archives that could be provided
through the network, e.g. as mail attachment or from a download
page.</p>
|