===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata22.html,v
retrieving revision 1.58
retrieving revision 1.59
diff -c -r1.58 -r1.59
*** www/errata22.html	2010/03/08 21:53:37	1.58
--- www/errata22.html	2010/07/08 19:00:07	1.59
***************
*** 52,58 ****
  <br>
  <hr>
  
! <a href="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  
--- 52,58 ----
  <br>
  <hr>
  
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2.tar.gz">
  You can also fetch a tar.gz file containing all the following patches</a>.
  This file is updated once a day.
  
***************
*** 70,76 ****
  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="ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ipsec.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li><a name="xterm-xaw"></a>
--- 70,76 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ipsec.patch">
  A source code patch exists which remedies this problem.</a>
  <p>
  <li><a name="xterm-xaw"></a>
***************
*** 85,91 ****
  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="ftp://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><a name="rmjob"></a>
--- 85,91 ----
  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="http://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><a name="rmjob"></a>
***************
*** 94,114 ****
  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>
  <li><a name="uucpd"></a>
  <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>
  <li><a name="named"></a>
  <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>
  <li><a name="ping"></a>
--- 94,114 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/rmjob.patch">
  A patch is available which corrects this behaviour</a>.
  <p>
  <li><a name="uucpd"></a>
  <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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/uucpd.patch">
  A patch is available which corrects this behaviour</a>.
  <p>
  <li><a name="named"></a>
  <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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/named.patch">
  A patch is available which corrects this behaviour</a>.
  <p>
  <li><a name="ping"></a>
***************
*** 117,123 ****
  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>
  <li><a name="sourceroute"></a>
--- 117,123 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/ping.patch">
  A patch is available which corrects this behaviour</a>.
  <p>
  <li><a name="sourceroute"></a>
***************
*** 129,135 ****
  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>
  <li><a name="ruserok"></a>
--- 129,135 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/sourceroute.patch">
  A kernel patch is provided</a>.
  <p>
  <li><a name="ruserok"></a>
***************
*** 145,155 ****
  <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>
--- 145,155 ----
  <p>
  <ul>
  <li>
! <a href="http://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="http://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>
***************
*** 172,178 ****
  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>
--- 172,178 ----
  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="http://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>
***************
*** 182,188 ****
  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>
  <li><a name="mountd"></a>
--- 182,188 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/readlink.c">
  A replacement source file exists</a>.
  <p>
  <li><a name="mountd"></a>
***************
*** 190,202 ****
  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>
--- 190,202 ----
  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="http://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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/common/send.patch">
  A patch</a> to return EINVAL in this case is available.
  <p>
  </ul>
***************
*** 210,228 ****
  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>
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><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="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>
--- 210,228 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/i386/f00f.patch">
  A kernel source-code patch is available</a>.
  <p>
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><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="http://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="http://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>
***************
*** 242,266 ****
  <li><font color="#009000"><strong>NEW SOFTWARE</strong></font><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="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>
  <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
--- 242,266 ----
  <li><font color="#009000"><strong>NEW SOFTWARE</strong></font><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="http://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz">
! http://ftp.OpenBSD.org/pub/OpenBSD/2.2/mac68k/X11/X11R6.tar.gz</a>.  Please
! be sure to read the <a href="http://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><font color="#009000"><strong>INSTALLATION PROCESS FLAW</strong></font><br>
  As shipped on the CDROM, both the
! <a href="http://ftp.openbsd.org/pub/OpenBSD/2.2/mac68k/bsd-generic.tar.gz">
  generic kernel</a>
  and the
! <a href="http://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="http://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
***************
*** 276,293 ****
  <li><font color="#009000"><strong>RELIABILITY FIX</strong></font><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="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>
  <li><a name="sparciommu"></a>
  <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>
--- 276,293 ----
  <li><font color="#009000"><strong>RELIABILITY FIX</strong></font><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="http://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="http://ftp.OpenBSD.org/pub/OpenBSD/patches/2.2/sparc/bsd">bsd</a>,
! <a href="http://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><a name="sparciommu"></a>
  <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="http://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>
***************
*** 297,303 ****
  <ul>
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  Missing Xamiga manual pages.  Get
! <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>
--- 297,303 ----
  <ul>
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><br>
  Missing Xamiga manual pages.  Get
! <a href="http://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>
***************
*** 313,329 ****
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><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="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>
  <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>
  <li><a name="ldso"></a>
--- 313,329 ----
  <li><font color="#009000"><strong>FUNCTIONALITY FIX</strong></font><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="http://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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.NFS">bsd.NFS</a>,
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd">bsd</a>,
! <a href="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/bsd.rz0">bsd.rz0</a>.
  <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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/fb.patch">
  A source code patch is available</a>.
  <p>
  <li><a name="ldso"></a>
***************
*** 331,337 ****
  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>
--- 331,337 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so">
  The replacement binary is here</a>.
  <p>
  </ul>
***************
*** 342,348 ****
  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>
--- 342,348 ----
  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="http://ftp.openbsd.org/pub/OpenBSD/patches/2.2/pmax/ld.so">
  The replacement binary is here</a>.
  <p>
  </ul>
***************
*** 405,411 ****
  <hr>
  <a href=index.html><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a> 
  <a href="mailto:www@openbsd.org">www@openbsd.org</a>
! <br><small>$OpenBSD: errata22.html,v 1.58 2010/03/08 21:53:37 deraadt Exp $</small>
  
  </body>
  </html>
--- 405,411 ----
  <hr>
  <a href=index.html><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a> 
  <a href="mailto:www@openbsd.org">www@openbsd.org</a>
! <br><small>$OpenBSD: errata22.html,v 1.59 2010/07/08 19:00:07 sthen Exp $</small>
  
  </body>
  </html>