===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/errata.html,v
retrieving revision 1.195
retrieving revision 1.196
diff -c -r1.195 -r1.196
*** www/errata.html	1999/09/14 02:53:10	1.195
--- www/errata.html	1999/09/14 05:44:58	1.196
***************
*** 36,49 ****
  <li><h3><font color=#e00000>All architectures</font></h3>
  <ul>
  <a name=cron></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  In cron(8), make sure argv[] is NULL terminated in the fake popen() and
  run sendmail as the user, not as root.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/012_cron.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=miscfs></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  The procfs and fdescfs filesystems had an overrun in their handling
  of uio_offset in their readdir() routines. (These filesystems are not
  enabled by default).
--- 36,49 ----
  <li><h3><font color=#e00000>All architectures</font></h3>
  <ul>
  <a name=cron></a>
! <li><font color=#009000><strong>SECURITY FIX: Aug 30, 1999</strong></font><br>
  In cron(8), make sure argv[] is NULL terminated in the fake popen() and
  run sendmail as the user, not as root.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/012_cron.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=miscfs></a>
! <li><font color=#009000><strong>SECURITY FIX: Aug 12, 1999</strong></font><br>
  The procfs and fdescfs filesystems had an overrun in their handling
  of uio_offset in their readdir() routines. (These filesystems are not
  enabled by default).
***************
*** 51,63 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=profil></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  Stop profiling (see profil(2)) when we execve() a new process.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/010_profil.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=ipsec_in_use></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  Packets that should have been handled by IPsec may be transmitted
  as cleartext. PF_KEY SA expirations may leak kernel resources.
  <a
--- 51,63 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=profil></a>
! <li><font color=#009000><strong>SECURITY FIX: Aug 9, 1999</strong></font><br>
  Stop profiling (see profil(2)) when we execve() a new process.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/010_profil.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=ipsec_in_use></a>
! <li><font color=#009000><strong>SECURITY FIX: Aug 6, 1999</strong></font><br>
  Packets that should have been handled by IPsec may be transmitted
  as cleartext. PF_KEY SA expirations may leak kernel resources.
  <a
***************
*** 65,85 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=rc></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  In /etc/rc, use mktemp(1) for motd re-writing, and change the find(1)
  to use -execdir.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/008_rc.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=chflags></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  Do not permit regular users to chflags(2) or fchflags(2) on character or
  block devices which they may currently be the owner of.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/007_chflags.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=nroff></a>
! <li><font color=#009000><strong>SECURITY FIX</strong></font><br>
  Cause groff(1) to be invoked with the -S flag, when called by nroff(1),
  to avoid various groff features which may be security issues.  On the
  whole, this is not really a security issue, but it was discussed on
--- 65,85 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=rc></a>
! <li><font color=#009000><strong>SECURITY FIX: Aug 5, 1999</strong></font><br>
  In /etc/rc, use mktemp(1) for motd re-writing, and change the find(1)
  to use -execdir.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/008_rc.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=chflags></a>
! <li><font color=#009000><strong>SECURITY FIX: Jul 30, 1999</strong></font><br>
  Do not permit regular users to chflags(2) or fchflags(2) on character or
  block devices which they may currently be the owner of.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/007_chflags.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=nroff></a>
! <li><font color=#009000><strong>SECURITY FIX: Jul 27, 1999</strong></font><br>
  Cause groff(1) to be invoked with the -S flag, when called by nroff(1),
  to avoid various groff features which may be security issues.  On the
  whole, this is not really a security issue, but it was discussed on
***************
*** 88,101 ****
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=fts></a>
! <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>
  Programs using fts(3) could dump core when given a directory structure
  with a very large number of entries.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/005_fts.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=tcpsack></a>
! <li><font color=#009000><strong>RELIABILITY FIX</strong></font><br>
  Sequence numbers could wrap with TCP_SACK and TCP_NEWRENO, resulting in
  failure to retransmit correctly.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/004_tcpsack.patch>
--- 88,101 ----
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=fts></a>
! <li><font color=#009000><strong>RELIABILITY FIX: May 19, 1999</strong></font><br>
  Programs using fts(3) could dump core when given a directory structure
  with a very large number of entries.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/005_fts.patch>
  A source code patch exists which remedies this problem.</a>
  <p>
  <a name=tcpsack></a>
! <li><font color=#009000><strong>RELIABILITY FIX: May 19, 1999</strong></font><br>
  Sequence numbers could wrap with TCP_SACK and TCP_NEWRENO, resulting in
  failure to retransmit correctly.
  <a href=ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.5/common/004_tcpsack.patch>
***************
*** 211,217 ****
  
  <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: errata.html,v 1.195 1999/09/14 02:53:10 deraadt Exp $</small>
  
  </body>
  </html>
--- 211,217 ----
  
  <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: errata.html,v 1.196 1999/09/14 05:44:58 deraadt Exp $</small>
  
  </body>
  </html>