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

Diff for /www/errata45.html between version 1.62 and 1.63

version 1.62, 2019/05/27 22:55:20 version 1.63, 2019/05/28 16:32:42
Line 86 
Line 86 
 <hr>  <hr>
   
 <ul>  <ul>
 <li id="p016_openssl">  
 <strong>016: SECURITY FIX: April 14, 2010</strong>  
 &nbsp; <i>All architectures</i><br>  
 In TLS connections, certain incorrectly formatted records can cause  
 an OpenSSL client or server to crash due to a read attempt at NULL.  
 <br>  
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/016_openssl.patch">  
 A source code patch exists which remedies this problem.</a>  
 <p>  
   
 <li id="p015_mpi">  <li id="p001_openssl">
 <strong>015: RELIABILITY FIX: April 4, 2010</strong>  <strong>001: RELIABILITY FIX: April 8, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 When updating sensors showing the state of RAID volumes  The OpenSSL ASN.1 handling code could be forced to perform invalid memory
 <a href="https://man.openbsd.org/OpenBSD-4.5/mpi.4">mpi(4)</a>  accesses through the use of certain invalid strings
 allocates temporary memory and then returns it to the kernel as  (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0590">CVE-2009-0590</a>)
 device memory.  or under certain error conditions triggerable by invalid ASN.1 structures
 This causes kernel memory usage to be misrepresented, eventually  (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0789">CVE-2009-0789</a>).
 leading to a denial of service when a resource limit is apparently  These vulnerabilities could be exploited to achieve a
 reached.  denial-of-service. A more detailed description of these problems is available
   in the
   <a href="http://www.openssl.org/news/secadv_20090325.txt">OpenSSL security advisory</a>, but note that the other issue described there "Incorrect Error
   Checking During CMS verification" relates to code not enabled in OpenBSD.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/015_mpi.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/001_openssl.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p014_kerberos">  <li id="p002_pf">
 <strong>014: RELIABILITY FIX: March 31, 2010</strong>  <strong>002: RELIABILITY FIX: April 11, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 When decrypting packets, the internal decryption functions were not  When pf attempts to perform translation on a specially crafted IP datagram,
 paranoid enough in checking for underruns, which could potentially  a null pointer dereference will occur, resulting in a kernel panic.
 lead to crashes.  In certain configurations this may be triggered by a remote attacker.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/014_kerberos.patch">  Restricting translation rules to protocols that are specific to the IP version
   in use, is an effective workaround until the patch can be installed. As an
   example, for IPv4 nat/binat/rdr rules you can use:
   <pre>
       nat/rdr ... inet proto { tcp udp icmp } ...
   </pre>
   Or for IPv6 nat/binat/rdr rules you can use:
   <pre>
       nat/rdr ... inet6 proto { tcp udp icmp6 } ...
   </pre>
   <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/002_pf.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p013_ftpd">  <li id="p003_bus_dma">
 <strong>013: RELIABILITY FIX: March 12, 2010</strong>  <strong>003: RELIABILITY FIX: April 24, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>i386 only</i><br>
 Due to a null pointer dereference, it would be possible to crash ftpd when  When DMA'able memory is mapped by device drivers, the
 handling glob(3)'ing requests. This is non-exploitable.  mapping flags and protection are partially uninitialized.
   Depending on the calling context, this may cause devices to misbehave, like
   <a href="https://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>
   to stutter, but other anomalies might be observed for other
   device types.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/013_ftpd.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/i386/003_bus_dma.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p012_openssl">  <li id="p004_aucat">
 <strong>012: SECURITY FIX: March 12, 2010</strong>  <strong>004: RELIABILITY FIX: April 24, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 OpenSSL is susceptible to a buffer overflow due to a failure  In server mode when in full-duplex mode (the default)
 to check for NULL returns from bn_wexpand function calls.  <a href="https://man.openbsd.org/OpenBSD-4.5/aucat.1">aucat(1)</a>
   will send each synchronization message twice, causing client applications
   to think that buffer underruns are occuring.  Depending on the
   application, this may cause the sound to stutter.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/012_openssl.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/004_aucat.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p011_ptrace">  <li id="p005_audio">
 <strong>011: RELIABILITY FIX: January 29, 2010</strong>  <strong>005: RELIABILITY FIX: April 24, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 By using ptrace(2) on an ancestor process, a loop in the process tree  On very high system load, an audio interrupt may occur while the
 could be created, violating assumptions in other parts of the kernel  audio process is filling audio ring buffers. This triggers bogus
 and resulting in infinite loops.  (and useless) correction code in the
   <a href="https://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>
   driver causing the audio application to go out of sync, and in turn causing
   continuous stuttering until the application is restarted.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/011_ptrace.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/005_audio.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p010_openssl">  <li id="p006_perl">
 <strong>010: SECURITY FIX: November 26, 2009</strong>  <strong>006: RELIABILITY FIX: June 24, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 The SSL/TLS protocol is subject to man-in-the-middle attacks related to  An off-by-one error in the inflate function in Zlib.xs in the
 renegotiation (see CVE-2009-3555, draft-ietf-tls-renegotiation-00).  Compress::Raw::Zlib perl module before 2.017 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1391">CVE-2009-1391</a>),
 OpenSSL permitted this protocol feature by default and had no way to  as used in AMaViS, SpamAssassin, and possibly other products,
 disable it.  allows context-dependent attackers to cause a denial of service
   (hang or crash) via a crafted zlib compressed stream that
   triggers a heap-based buffer overflow.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/010_openssl.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/006_perl_zlib.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p009_getsockopt">  <li id="p007_bind">
 <strong>009: RELIABILITY FIX: October 28, 2009</strong>  <strong>007: RELIABILITY FIX: July 29, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 getsockopt(2) with any of IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL,  A vulnerability has been found in BIND's named server
 IP_IPCOMP_LEVEL will crash the system.  (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696">CVE-2009-0696</a>).
   An attacker could crash a server with a specially crafted dynamic update message to a
   zone for which the server is master.
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/009_getsockopt.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/007_bind.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
Line 184 
Line 202 
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p007_bind">  <li id="p009_getsockopt">
 <strong>007: RELIABILITY FIX: July 29, 2009</strong>  <strong>009: RELIABILITY FIX: October 28, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 A vulnerability has been found in BIND's named server  getsockopt(2) with any of IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL,
 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696">CVE-2009-0696</a>).  IP_IPCOMP_LEVEL will crash the system.
 An attacker could crash a server with a specially crafted dynamic update message to a  
 zone for which the server is master.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/007_bind.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/009_getsockopt.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p006_perl">  <li id="p010_openssl">
 <strong>006: RELIABILITY FIX: June 24, 2009</strong>  <strong>010: SECURITY FIX: November 26, 2009</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 An off-by-one error in the inflate function in Zlib.xs in the  The SSL/TLS protocol is subject to man-in-the-middle attacks related to
 Compress::Raw::Zlib perl module before 2.017 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1391">CVE-2009-1391</a>),  renegotiation (see CVE-2009-3555, draft-ietf-tls-renegotiation-00).
 as used in AMaViS, SpamAssassin, and possibly other products,  OpenSSL permitted this protocol feature by default and had no way to
 allows context-dependent attackers to cause a denial of service  disable it.
 (hang or crash) via a crafted zlib compressed stream that  
 triggers a heap-based buffer overflow.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/006_perl_zlib.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/010_openssl.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
   <li id="p011_ptrace">
   <strong>011: RELIABILITY FIX: January 29, 2010</strong>
   &nbsp; <i>All architectures</i><br>
   By using ptrace(2) on an ancestor process, a loop in the process tree
   could be created, violating assumptions in other parts of the kernel
   and resulting in infinite loops.
   <br>
   <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/011_ptrace.patch">
   A source code patch exists which remedies this problem.</a>
   <p>
   
 <li id="p005_audio">  <li id="p012_openssl">
 <strong>005: RELIABILITY FIX: April 24, 2009</strong>  <strong>012: SECURITY FIX: March 12, 2010</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 On very high system load, an audio interrupt may occur while the  OpenSSL is susceptible to a buffer overflow due to a failure
 audio process is filling audio ring buffers. This triggers bogus  to check for NULL returns from bn_wexpand function calls.
 (and useless) correction code in the  
 <a href="https://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>  
 driver causing the audio application to go out of sync, and in turn causing  
 continuous stuttering until the application is restarted.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/005_audio.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/012_openssl.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p004_aucat">  <li id="p013_ftpd">
 <strong>004: RELIABILITY FIX: April 24, 2009</strong>  <strong>013: RELIABILITY FIX: March 12, 2010</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 In server mode when in full-duplex mode (the default)  Due to a null pointer dereference, it would be possible to crash ftpd when
 <a href="https://man.openbsd.org/OpenBSD-4.5/aucat.1">aucat(1)</a>  handling glob(3)'ing requests. This is non-exploitable.
 will send each synchronization message twice, causing client applications  
 to think that buffer underruns are occuring.  Depending on the  
 application, this may cause the sound to stutter.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/004_aucat.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/013_ftpd.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p003_bus_dma">  <li id="p014_kerberos">
 <strong>003: RELIABILITY FIX: April 24, 2009</strong>  <strong>014: RELIABILITY FIX: March 31, 2010</strong>
 &nbsp; <i>i386 only</i><br>  &nbsp; <i>All architectures</i><br>
 When DMA'able memory is mapped by device drivers, the  When decrypting packets, the internal decryption functions were not
 mapping flags and protection are partially uninitialized.  paranoid enough in checking for underruns, which could potentially
 Depending on the calling context, this may cause devices to misbehave, like  lead to crashes.
 <a href="https://man.openbsd.org/OpenBSD-4.5/audio.4">audio(4)</a>  
 to stutter, but other anomalies might be observed for other  
 device types.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/i386/003_bus_dma.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/014_kerberos.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p002_pf">  <li id="p015_mpi">
 <strong>002: RELIABILITY FIX: April 11, 2009</strong>  <strong>015: RELIABILITY FIX: April 4, 2010</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 When pf attempts to perform translation on a specially crafted IP datagram,  When updating sensors showing the state of RAID volumes
 a null pointer dereference will occur, resulting in a kernel panic.  <a href="https://man.openbsd.org/OpenBSD-4.5/mpi.4">mpi(4)</a>
 In certain configurations this may be triggered by a remote attacker.  allocates temporary memory and then returns it to the kernel as
   device memory.
   This causes kernel memory usage to be misrepresented, eventually
   leading to a denial of service when a resource limit is apparently
   reached.
 <br>  <br>
 Restricting translation rules to protocols that are specific to the IP version  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/015_mpi.patch">
 in use, is an effective workaround until the patch can be installed. As an  
 example, for IPv4 nat/binat/rdr rules you can use:  
 <pre>  
     nat/rdr ... inet proto { tcp udp icmp } ...  
 </pre>  
 Or for IPv6 nat/binat/rdr rules you can use:  
 <pre>  
     nat/rdr ... inet6 proto { tcp udp icmp6 } ...  
 </pre>  
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/002_pf.patch">  
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
 <li id="p001_openssl">  <li id="p016_openssl">
 <strong>001: RELIABILITY FIX: April 8, 2009</strong>  <strong>016: SECURITY FIX: April 14, 2010</strong>
 &nbsp; <i>All architectures</i><br>  &nbsp; <i>All architectures</i><br>
 The OpenSSL ASN.1 handling code could be forced to perform invalid memory  In TLS connections, certain incorrectly formatted records can cause
 accesses through the use of certain invalid strings  an OpenSSL client or server to crash due to a read attempt at NULL.
 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0590">CVE-2009-0590</a>)  
 or under certain error conditions triggerable by invalid ASN.1 structures  
 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0789">CVE-2009-0789</a>).  
 These vulnerabilities could be exploited to achieve a  
 denial-of-service. A more detailed description of these problems is available  
 in the  
 <a href="http://www.openssl.org/news/secadv_20090325.txt">OpenSSL security advisory</a>, but note that the other issue described there "Incorrect Error  
 Checking During CMS verification" relates to code not enabled in OpenBSD.  
 <br>  <br>
 <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/001_openssl.patch">  <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/016_openssl.patch">
 A source code patch exists which remedies this problem.</a>  A source code patch exists which remedies this problem.</a>
 <p>  <p>
   
Legend:
Removed from v.1.62  
changed lines
  Added in v.1.63