[BACK]Return to errata.html CVS log [TXT][DIR] Up to [local] / www

Diff for /www/errata.html between version 1.92 and 1.93

version 1.92, 1998/04/22 14:55:30 version 1.93, 1998/04/23 14:28:13
Line 14 
Line 14 
   
 <img alt="[OpenBSD]" SRC="images/smalltitle.gif">  <img alt="[OpenBSD]" SRC="images/smalltitle.gif">
 <h2><font color=#0000e0>  <h2><font color=#0000e0>
 This is the OpenBSD 2.2 release errata & patch list:  This is the OpenBSD 2.3 release errata & patch list:
 </font></h2>  </font></h2>
   
 <ul>  <ul>
 <a name=all></a>  <a name=all></a>
 <li><h3><font color=#e00000>All architectures</font></h3>  <li><h3><font color=#e00000>All architectures</font></h3>
 <ul>  <ul>
 <a name=rmjob></a>  <li>No problems identified yet.
 <li><font color=#009000><strong>SECURITY FIX</strong></font><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 <strong>/etc/printcap</strong> which  
 points at a remote printer.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/rmjob.patch>  
 A patch is available which corrects this behaviour</a>.  
 <p>  <p>
 <a name=uucpd></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/uucpd.patch>  
 A patch is available which corrects this behaviour</a>.  
 <p>  
 <a name=named></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><br>  
 A vulnerability exists when (and only when) /etc/named.conf has the  
 <strong>fake-iquery</strong> option enabled.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/named.patch>  
 A patch is available which corrects this behaviour</a>.  
 <p>  
 <a name=ping></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ping.patch>  
 A patch is available which corrects this behaviour</a>.  
 <p>  
 <a name=sourceroute></a>  
 <li><strong><font color=#009000>SECURITY FIX</strong></font><br>  
 If the sysctl variable <strong>net.inet.ip.forwarding</strong> is  
 enabled (value 1), but the variable <strong>net.inet.ip.sourceroute</strong>  
 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 <strong>net.inet.ip.sourceroute</strong>  
 variable semantics to mean that all source routed packets should  
 be blocked completely.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/sourceroute.patch>  
 A kernel patch is provided</a>.  
 <p>  
 <a name=ruserok></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><br>  
 A combination localhost+remote host security problem exists if a  
 local user running a setuid binary causes a non-existant 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=ftp://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=ftp://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>  </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>  
 <a name=mmap></a>  
 <li><strong><font color=#009000>SECURITY FIX</strong></font><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=ftp://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>.  
 <p>  
 <li><font color=#009000><strong>BUILD PROCESS FIX</strong></font><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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/readlink.c>  
 A replacement source file exists</a>.  
 <p>  
 <a name=mountd></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/mountd.patch>  
 A patch is available which corrects this behaviour</a>.  
 <p>  
 <li><font color=#009000><strong>RELIABILITY FIX</strong></font><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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/send.patch>  
 A patch</a> to return EINVAL in this case is available.  
 <p>  
 </ul>  
 <a name=i386></a>  <a name=i386></a>
 <li><h3><font color=#e00000>i386</font></h3>  <li><h3><font color=#e00000>i386</font></h3>
 <ul>  <ul>
 <a name=f00f></a>  <li>No problems identified yet.
 <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>  
 The Intel P5 F00F bug was discovered after the CDR's 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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/f00f.patch>  
 A kernel source-code patch is available</a>.  
 <p>  <p>
 <li><font color=#009000><strong>FUNCTIONALITY FIX</strong></font><br>  
 Some Linux binaries will execute in SVR4 emulation mode, which is  
 definately a problem for people who need Linux emulation to work correctly.  
 To solve this mis-identification problem,  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/compat_linux.patch>  
 a patch file is provided</a>.  
 <p>  
 <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>  
 APM can crash on machines without it.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/apm.patch>  
 A kernel source-code patch is available</a>.  
 <p>  
 <li><font color=#009000><strong>INSTALLATION PROCESS FLAW</strong></font><br>  
 A few people are running into this problem, particularily 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>  
 </ul>  </ul>
 <a name=mac68k></a>  <a name=mac68k></a>
 <li><h3><font color=#e00000>mac68k</font></h3>  <li><h3><font color=#e00000>mac68k</font></h3>
 <ul>  <ul>
 <li><font color=#009000><strong>NEW SOFTWARE</strong></font><br>  <li>No problems identified yet.
 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="ftp://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz">  
 ftp://ftp.OpenBSD.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz</a>.  Please  
 be sure to read the <a href="ftp://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>  <p>
 <li><font color=#009000><strong>INSTALLATION PROCESS FLAW</strong></font><br>  
 As shipped on the CDROM, both the  
 <a href="ftp://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/bsd-generic.tar.gz">  
 generic kernel</a>  
 and the  
 <a href="ftp://ftp.openbsd.org/pub/OpenBSD/2.2/bsd-genericbsc.tar.gz">  
 genericsbc kernel</a>  
 extract themselves into the wrong place in the filesystem.  
 Both <strong>should</strong> extract a kernel named <tt>/bsd</tt>, but they extract  
 the kernel into <tt>/usr/src/sys/arch/mac68k/compile</tt> 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="ftp://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k">  
 ftp://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 <tt>/usr/src/...</tt> to <tt>/bsd</tt>.  
 <p>  
 </ul>  </ul>
 <a name=sparc></a>  <a name=sparc></a>
 <li><h3><font color=#e00000>sparc</font></h3>  <li><h3><font color=#e00000>sparc</font></h3>
 <ul>  <ul>
 <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>  <li>No problems identified yet.
 Older 4/xxx systems (particularily the 4/300's) cannot boot  
 with the 2.2 kernel due to bugs in the scsi device driver.  
 <a href=ftp://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=ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/bsd>bsd</a>,  
 <a href=ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/bsd.scsi3>bsd.scsi3</a>,  
 and a replacement for bsd.rd is coming soon.  
 <p>  <p>
 <a name=sparciommu></a>  
 <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>  
 SPARCstation 4 and 5 (Microsparc 2) users may see kernel panics when  
 using a custom kernel configured for option sun4m only.  
 <a href=ftp://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>  
 </ul>  </ul>
   <a name=amiga></a>
 <li><h3><font color=#e00000>amiga</font></h3>  <li><h3><font color=#e00000>amiga</font></h3>
 <p>  
 <ul>  <ul>
 <li><font color=#009000><strong>FUNCTIONALITY FIX</strong></font><br>  <li>No problems identified yet.
 Missing Xamiga manual pages.  Get  <p>
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/amiga/Xamiga-manual.tgz>  
 this package</a> and execute, <i>as root</i>:<br>  
 <strong><b># </b>pkg_add Xamiga-manual.tgz</strong><br>  
 The MD5 checksum of this package is:<br>  
 <b>MD5 (Xamiga-manual.tgz) = 2362a7857264b9d17f65cca258b42031</b><p>  
 <li><font color=#009000><strong>FUNCTIONALITY FIX</strong></font><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>  
 </ul>  </ul>
 <a name=pmax></a>  <a name=pmax></a>
 <li><h3><font color=#e00000>pmax</font></h3>  <li><h3><font color=#e00000>pmax</font></h3>
 <ul>  <ul>
 <li><font color=#009000><strong>FUNCTIONALITY FIX</strong></font><br>  <li>No problems identified yet.
 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=ftp://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=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.NFS>bsd.NFS</a>,  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd>bsd</a>,  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.rz0>bsd.rz0</a>.  
 <p>  <p>
 <li><font color=#009000><strong>FUNCTIONALITY FIX</strong></font><br>  
 X11 support for the 3min and 3maxplus machines was broken  
 due to a kernel bug.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/fb.patch>  
 A source code patch is available</a>.  
 <p>  
 <a name=ldso></a>  
 <li><font color=#009000><strong>SECURITY FIX</strong></font><br>  
 A security problem in the shared library linker <strong>ld.so</strong>  
 requires that you replace it with a new binary.  The following binary  
 will work on both pmax and arc machines.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so>  
 The replacement binary is here</a>.  
 <p>  
 </ul>  </ul>
 <a name=arc></a>  <a name=arc></a>
 <li><h3><font color=#e00000>arc</font></h3>  <li><h3><font color=#e00000>arc</font></h3>
 <ul>  <ul>
 <li><font color=#009000><strong>SECURITY FIX</strong></font><br>  <li>No problems identified yet.
 A security problem in the shared library linker <strong>ld.so</strong> requires  
 that you replace it with a new binary.  The following binary  
 will work on both pmax and arc machines.  
 <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so>  
 The replacement binary is here</a>.  
 <p>  <p>
 </ul>  </ul>
   <a name=alpha></a>
 <li><h3><font color=#e00000>alpha</font></h3>  <li><h3><font color=#e00000>alpha</font></h3>
 <p>  
 <ul>  <ul>
 <li><font color=#009000><strong>MISSING FUNCTIONALITY</strong></font><br>  <li>No problems identified yet.
 Network Address Translation and other parts of IP Filtering to 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>  <p>
 </ul>  </ul>
   <a name=hp300></a>
 <li><h3><font color=#e00000>hp300</font></h3>  <li><h3><font color=#e00000>hp300</font></h3>
 <p>  <p>
 <ul>  <ul>
 <li>No problems identified yet.  <li>No problems identified yet.
 <p>  <p>
 </ul>  </ul>
   <a name=mvme68k></a>
 <li><h3><font color=#e00000>mvme68k</font></h3>  <li><h3><font color=#e00000>mvme68k</font></h3>
 <ul>  <ul>
 <li>No problems identified yet.  <li>No problems identified yet.
Line 303 
Line 83 
 <br>  <br>
   
 <hr>  <hr>
 <a href=errata21.html>For 2.1 errata, please refer here</a>.  <a href=errata21.html>For 2.1 errata, please refer here</a>.<br>
   <a href=errata22.html>For 2.2 errata, please refer here</a>.<br>
 <hr>  <hr>
 <a href=orders.html><img src=back.gif border=0 alt=OpenBSD></a>  <a href=orders.html><img src=back.gif border=0 alt=OpenBSD></a>
 <a href=mailto:www@openbsd.org>www@openbsd.org</a>  <a href=mailto:www@openbsd.org>www@openbsd.org</a>
Legend:
Removed from v.1.92  
changed lines
  Added in v.1.93