forked from openbsd/www
-
Notifications
You must be signed in to change notification settings - Fork 0
/
errata22.html
414 lines (376 loc) · 16.4 KB
/
errata22.html
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
405
406
407
408
409
410
411
412
413
414
<!doctype html>
<html lang=en id=errata>
<meta charset=utf-8>
<title>OpenBSD 2.2 Errata</title>
<meta name="description" content="the OpenBSD CD errata page">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="openbsd.css">
<link rel="canonical" href="https://www.openbsd.org/errata22.html">
<!--
IMPORTANT REMINDER
IF YOU ADD A NEW ERRATUM, MAIL THE PATCH TO TECH AND ANNOUNCE
-->
<h2 id=OpenBSD>
<a href="index.html">
<i>Open</i><b>BSD</b></a>
2.2 Errata
</h2>
<hr>
For errata on a certain release, click below:<br>
<a href="errata20.html">2.0</a>,
<a href="errata21.html">2.1</a>,
<a href="errata23.html">2.3</a>,
<a href="errata24.html">2.4</a>,
<a href="errata25.html">2.5</a>,
<a href="errata26.html">2.6</a>,
<a href="errata27.html">2.7</a>,
<a href="errata28.html">2.8</a>,
<a href="errata29.html">2.9</a>,
<a href="errata30.html">3.0</a>,
<a href="errata31.html">3.1</a>,
<a href="errata32.html">3.2</a>,
<a href="errata33.html">3.3</a>,
<a href="errata34.html">3.4</a>,
<a href="errata35.html">3.5</a>,
<a href="errata36.html">3.6</a>,
<br>
<a href="errata37.html">3.7</a>,
<a href="errata38.html">3.8</a>,
<a href="errata39.html">3.9</a>,
<a href="errata40.html">4.0</a>,
<a href="errata41.html">4.1</a>,
<a href="errata42.html">4.2</a>,
<a href="errata43.html">4.3</a>,
<a href="errata44.html">4.4</a>,
<a href="errata45.html">4.5</a>,
<a href="errata46.html">4.6</a>,
<a href="errata47.html">4.7</a>,
<a href="errata48.html">4.8</a>,
<a href="errata49.html">4.9</a>,
<a href="errata50.html">5.0</a>,
<a href="errata51.html">5.1</a>,
<a href="errata52.html">5.2</a>,
<br>
<a href="errata53.html">5.3</a>,
<a href="errata54.html">5.4</a>,
<a href="errata55.html">5.5</a>,
<a href="errata56.html">5.6</a>,
<a href="errata57.html">5.7</a>,
<a href="errata58.html">5.8</a>,
<a href="errata59.html">5.9</a>,
<a href="errata60.html">6.0</a>,
<a href="errata61.html">6.1</a>,
<a href="errata62.html">6.2</a>,
<a href="errata63.html">6.3</a>,
<a href="errata64.html">6.4</a>,
<a href="errata65.html">6.5</a>,
<a href="errata66.html">6.6</a>,
<a href="errata67.html">6.7</a>,
<a href="errata68.html">6.8</a>,
<br>
<a href="errata69.html">6.9</a>,
<a href="errata70.html">7.0</a>.
<hr>
<p>
Patches for the OpenBSD base system are distributed as unified diffs.
Each patch contains usage instructions.
All the following patches are also available in one
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2.tar.gz">tar.gz file</a>
for convenience.
<p>
Patches for supported releases are also incorporated into the
<a href="stable.html">-stable branch</a>.
<hr>
<ul>
<li id="ipsec">
<strong>001: SECURITY FIX</strong>
<i>All architectures</i><br>
If IPSEC communication is attempted by starting photurisd(8) (which is
disabled by default), a system crash may be evoked from remote if
an attacker uses some classes of invalid packets.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ipsec.patch">
A source code patch exists which remedies this problem.</a>
<p>
<li id="xterm-xaw">
<strong>002: SECURITY FIX</strong>
<i>All architectures</i><br>
As stated in CERT advisory VB-98.04, there are buffer
overrun problems in <b>xterm</b> related to the input-Method,
preeditType, and *Keymap resources. Additional buffer overruns exist in
the <b>Xaw</b> library related to the inputMethod and
preeditType resources. The xterm(1) problem represents a security
vulnerability for any platform where xterm is installed setuid-root
(as is the case for all OpenBSD platforms). The Xaw problem represents
a security vulnerability for any setuid-root program that uses the Xaw
library (including xterm). Patch1 from XFree86 3.3.2 corrects
these problems.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/xterm-xaw.patch">
We provide a version of this patch file specifically for the OpenBSD 2.2 tree</a>.
<p>
<li id="rmjob">
<strong>003: SECURITY FIX</strong>
<i>All architectures</i><br>
An exploitable buffer mismanagement exists in a subroutine used by
lprm and lpd. The problem is exploitable by users on a particular
machine if there is an entry in <b>/etc/printcap</b> which
points at a remote printer.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/rmjob.patch">
A patch is available which corrects this behaviour</a>.
<p>
<li id="uucpd">
<strong>004: SECURITY FIX</strong>
<i>All architectures</i><br>
A DNS-based vulnerability exists when uucpd is used. By default uucpd
is not enabled in the OpenBSD releases, but some sites may have enabled it.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/uucpd.patch">
A patch is available which corrects this behaviour</a>.
<p>
<li id="named">
<strong>005: SECURITY FIX</strong>
<i>All architectures</i><br>
A vulnerability exists when (and only when) /etc/named.conf has the
<b>fake-iquery</b> option enabled.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/named.patch">
A patch is available which corrects this behaviour</a>.
<p>
<li id="ping">
<strong>006: SECURITY FIX</strong>
<i>All architectures</i><br>
A vulnerability exists in ping(8); if the -R option is used to record
routes, an attacker can spoof a reply packet that will overflow inside
ping. Preliminary investigation makes it look the worst attack
possible is to make ping crash, but one never knows...
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ping.patch">
A patch is available which corrects this behaviour</a>.
<p>
<li id="sourceroute">
<strong>007: SECURITY FIX</strong> <i>All architectures</i><br>
If the sysctl variable <b>net.inet.ip.forwarding</b> is
enabled (value 1), but the variable <b>net.inet.ip.sourceroute</b>
is disabled (value 0), the kernel will block source routed packets from
going through, but will still accept source routing packets destined for
itself. Our fix changes the <b>net.inet.ip.sourceroute</b>
variable semantics to mean that all source routed packets should
be blocked completely.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/sourceroute.patch">
A kernel patch is provided</a>.
For more details, see the <a href="advisories/sourceroute.txt">OpenBSD
advisory</a>.
<p>
<li id="ruserok">
<strong>008: SECURITY FIX</strong>
<i>All architectures</i><br>
A combination localhost+remote host security problem exists if a
local user running a setuid binary causes a non-existent root .rhosts
file to be created via a symbolic link with a specific kind of corefile,
and then subsequently uses rsh/rlogin to enter the machine from remote.
A similar exploit might also be possible using sshd which lacks any code
for checking for deviations from the expected format in the .rhosts or
.shosts files, but we have not confirmed this yet. The following two
fixes are recommended:
<p>
<ul>
<li>
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/nosuidcoredump.patch">
(1) A kernel patch which adds a new sysctl option which permits the
administrator to decide whether setuid corefiles should be written or not</a>.
<p>
<li><a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/rcmd.patch">
(2) Replaces the libc ruserok() function with a more paranoid
version which detects bogus looking .rhosts files better.</a>
</ul>
<p>
If the
first patch is used to stop setuid coredumps, then the second patch is
not as important.
This problem is fixed much better in OpenBSD-current, where the kernel's
symbolic link handling has been improved such that coredumping will not
create a file on the other side of a symbolic link. Such a patch is not
possible for the 4.4lite1 VFS layer in the OpenBSD 2.2 kernel.<p>
The problem with the ruserok() function appears to also exist in
ssh 1.2.21 and previous (the ssh people have been alerted).
<p>
<li id="mmap">
<strong>009: SECURITY FIX</strong> <i>All architectures</i><br>
A bug in the vm system permits a file descriptor opened read-only on a
device, to later on be mmap(2)'d read-write, and then modified. This
does not result in a security hole by itself, but it does violate the
safety semantics which securelevels are supposed to provide. If a user
manages to gain kmem group permissions, using this problem they can then
gain root trivially and/or turn securelevels off.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/vm_mmap.patch">
A kernel patch is available which corrects this behaviour (this is
revision 3 of this patch)</a>.
For more details, see the <a href="advisories/mmap.txt">OpenBSD advisory</a>.
<p>
<li id="build1">
<strong>010: BUILD PROCESS FIX</strong>
<i>All architectures</i><br>
Building an object tree from a read-only source tree (such as off a CDROM)
may fail under certain circumstances (e.g. when creating a symlink on sparc
whose target name is exactly 33 characters). As a workaround you have to
either provide the source tree read/write, or install a newer version of
/usr/bin/readlink.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/readlink.c">
A replacement source file exists</a>.
<p>
<li id="mountd">
<strong>011: SECURITY FIX</strong>
<i>All architectures</i><br>
If a line in /etc/exports which contains hostnames results in an empty
list because none of the supplied hostnames is known, mountd(8) will
accidentally export the filesystem to the world.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/mountd.patch">
A patch is available which corrects this behaviour</a>.
<p>
<li id="eor">
<strong>012: RELIABILITY FIX</strong>
<i>All architectures</i><br>
Setting the MSG_EOR flag on a tcp packet in the send(2) family of
system calls could cause a kernel panic.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/send.patch">
A patch</a> to return EINVAL in this case is available.
<p>
<li id="f00f">
<strong>013: RELIABILITY FIX</strong><br>
The Intel P5 F00F bug was discovered after the CDRs had already been
sent to the manufacturer. This problem permits any user who has an account
to lock your machine up using a 4-line program. The problem only affects
Intel P5 processors (the i386, i486, P-Pro, and P-II are not vulnerable,
nor are processors by other manufacturers).
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/f00f.patch">
A kernel source-code patch is available</a>.
<p>
<li id="svr4">
<strong>014: FUNCTIONALITY FIX</strong><br>
Some Linux binaries will execute in SVR4 emulation mode, which is
definitely a problem for people who need Linux emulation to work correctly.
To solve this mis-identification problem,
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/compat_linux.patch">
a patch file is provided</a>.
<p>
<li id="apm">
<strong>015: RELIABILITY FIX</strong><br>
APM can crash on machines without it.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/apm.patch">
A kernel source-code patch is available</a>.
<p>
<li id="ide">
<strong>016: INSTALLATION PROCESS FLAW</strong><br>
A few people are running into this problem, particularly if they had some
other *BSD operating system on their machine before trying OpenBSD: if after
installation onto an IDE-based machine, the kernel fails to mount the root
partition because it thinks that it should be opening sd0 (0x400), this means
you have incorrectly setup your disklabel for the IDE drive -- the disklabel
is indicating that the drive is SCSI.
To repair this, use the floppy to run "disklabel -E wd0", then using the
"edit" command ensure the type field is set to "ST506".
<p>
<li id="mac68kx">
<strong>017: NEW SOFTWARE</strong><br>
Unfortunately, X11 binaries for the mac68k did not manage to make it onto the
CDROM. However, X11 for the mac68k is immediately available from
<a href="https://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz">
https://ftp.OpenBSD.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz</a>. Please
be sure to read the <a href="https://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/X11/README.X11">README file</a> also in that directory for instructions on installing
and setting up X.
<p>
<li id="mac68kpath">
<strong>018: INSTALLATION PROCESS FLAW</strong><br>
As shipped on the CDROM, both the
<a href="https://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/bsd-generic.tar.gz">
generic kernel</a>
and the
<a href="https://ftp.openbsd.org/pub/OpenBSD/2.2/bsd-genericbsc.tar.gz">
genericsbc kernel</a>
extract themselves into the wrong place in the filesystem.
Both <em>should</em> extract a kernel named <code>/bsd</code>, but they extract
the kernel into <code>/usr/src/sys/arch/mac68k/compile</code> instead.
<p>
This has been fixed on the ftp release of <a href=22.html>OpenBSD 2.2</a>, and
fresh kernels are available from <a href="https://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k">
http://ftp.OpenBSD.ORG/pub/OpenBSD/2.2/mac68k/</a>. If at all possible,
installing these kernels is recommended.
<p>
A number of possible workarounds exist if you don't have easy access to ftp
the updated kernels. The simplest of these is to use a
MacOS program to uncompress and untar the kernel aad use the Installer's
mini-shell to "cpin" the kernel. Alternately, you could install the kernel
with the Installer and use the mini-shell to move the binary from <code>/usr/src/...</code> to <code>/bsd</code>.
<p>
<li id="4300">
<strong>019: RELIABILITY FIX</strong><br>
Older 4/xxx systems (particularly the 4/300's) cannot boot
with the 2.2 kernel due to bugs in the scsi device driver.
<a href="https://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/esp.patch">
A kernel source patch is available</a>.
Replacement kernels are available for:
<a href="https://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/bsd">bsd</a>,
<a href="https://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/bsd.scsi3">bsd.scsi3</a>,
and a replacement for bsd.rd is coming soon.
<p>
<li id="sparciommu">
<strong>020: RELIABILITY FIX</strong><br>
SPARCstation 4 and 5 (Microsparc 2) users may see kernel panics when
using a custom kernel configured for option sun4m only.
<a href="https://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/sun4m.patch">
A workaround (kernel source patch) is available</a>. Apply the patch and
then re-build your kernel.
<p>
<li id="xamiga">
<strong>021: FUNCTIONALITY FIX</strong><br>
Missing Xamiga manual pages. Get
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/amiga/Xamiga-manual.tgz">
this package</a> and execute, <i>as root</i>:<br>
<b><b># </b>pkg_add Xamiga-manual.tgz</b><br>
The MD5 checksum of this package is:<br>
<b>MD5 (Xamiga-manual.tgz) = 2362a7857264b9d17f65cca258b42031</b>
<p>
<li id="araidne">
<strong>022: FUNCTIONALITY FIX</strong><br>
The Ariadne ethernet support was broken, there will be both binary and
source level fixes available shortly. If you are in a hurry mail
<a href="mailto:niklas@openbsd.org">Niklas</a> for a test kernel.<p>
<p>
<li id="pmax">
<strong>023: FUNCTIONALITY FIX</strong><br>
There is a Year-1998 problem in the time-setting code (which causes the
date and time to be set incorrectly after a reboot in 1998).
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/clock.patch">
A source code patch file is available</a> plus replacement installation
kernels for the 2.2 release at
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.NFS">bsd.NFS</a>,
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd">bsd</a>,
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.rz0">bsd.rz0</a>.
<p>
<li id="3min">
<strong>024: FUNCTIONALITY FIX</strong><br>
X11 support for the 3min and 3maxplus machines was broken
due to a kernel bug.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/fb.patch">
A source code patch is available</a>.
<p>
<li id="ldso">
<strong>025: SECURITY FIX</strong><br>
A security problem in the shared library linker <b>ld.so</b>
requires that you replace it with a new binary. The following binary
will work on both pmax and arc machines.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so">
The replacement binary is here</a>.
<p>
<li id="ldso2">
<strong>026: SECURITY FIX</strong><br>
A security problem in the shared library linker <b>ld.so</b> requires
that you replace it with a new binary. The following binary
will work on both pmax and arc machines.
<a href="https://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so">
The replacement binary is here</a>.
<p>
<li id="nat">
<strong>027: MISSING FUNCTIONALITY</strong><br>
Network Address Translation and other parts of IP Filtering do not work
on the alpha. This will be fixed in the 2.3 release, and perhaps earlier
in a snapshot. There is no patch for 2.2.
<p>
</ul>
<hr>