Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl

2006-09-28 Thread Bill Moran

Can anyone define exceptionally large as noted in this statement?:

NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by
prohibiting the use of exceptionally large public keys.  It is believed
that no existing applications legitimately use such key lengths as would
be affected by this change.

It would be nice if exceptionally large were replaced with keys in
excess of x bits in size or something.  I don't expect that this will
affect me, but ambiguous statements like that make me uncomfortable.

Begin forwarded message:

Date: Thu, 28 Sep 2006 13:13:53 GMT
From: FreeBSD Security Advisories [EMAIL PROTECTED]
To: FreeBSD Security Advisories [EMAIL PROTECTED]
Cc: 
Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
FreeBSD-SA-06:23.opensslSecurity Advisory
  The FreeBSD Project

Topic:  Multiple problems in crypto(3)

Category:   contrib
Module: openssl
Announced:  2006-09-28
Credits:Dr S N Henson, Tavis Ormandy, Will Drewry
Affects:All FreeBSD releases.
Corrected:  2006-09-28 13:02:37 UTC (RELENG_6, 6.1-PRERELEASE)
2006-09-28 13:03:14 UTC (RELENG_6_1, 6.1-RELEASE-p8)
2006-09-28 13:03:41 UTC (RELENG_6_0, 6.0-RELEASE-p13)
2006-09-28 13:03:57 UTC (RELENG_5, 5.5-STABLE)
2006-09-28 13:04:16 UTC (RELENG_5_5, 5.5-RELEASE-p6)
2006-09-28 13:04:47 UTC (RELENG_5_4, 5.4-RELEASE-p20)
2006-09-28 13:05:08 UTC (RELENG_5_3, 5.3-RELEASE-p35)
2006-09-28 13:05:59 UTC (RELENG_4, 4.11-STABLE)
2006-09-28 13:06:23 UTC (RELENG_4_11, 4.11-RELEASE-p23)
CVE Name:   CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit URL:http://security.FreeBSD.org/.

I.   Background

FreeBSD includes software from the OpenSSL Project.  The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured,
and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II.  Problem Description

Several problems have been found in OpenSSL:

1. During the parsing of certain invalid ASN1 structures an error condition
is mishandled, possibly resulting in an infinite loop.  [CVE-2006-2937]

2. A buffer overflow exists in the SSL_get_shared_ciphers function.
[CVE-2006-3738]

3. A NULL pointer may be dereferenced in the SSL version 2 client code.
[CVE-2006-4343]

In addition, many applications using OpenSSL do not perform any validation
of the lengths of public keys being used. [CVE-2006-2940]

III. Impact

Servers which parse ASN1 data from untrusted sources may be vulnerable to
a denial of service attack. [CVE-2006-2937]

An attacker accessing a server which uses SSL version 2 may be able to
execute arbitrary code with the privileges of that server.  [CVE-2006-3738]

A malicious SSL server can cause clients connecting using SSL version 2 to
crash. [CVE-2006-4343]

Applications which perform public key operations using untrusted keys may
be vulnerable to a denial of service attack. [CVE-2006-2940]

IV.  Workaround

No workaround is available, but not all of the vulnerabilities mentioned
affect all applications.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE,
or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, RELENG_5_3,
or RELENG_4_11 security branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 4.11, 5.3,
5.4, 5.5, 6.0, and 6.1 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-06:23/openssl.patch
# fetch http://security.FreeBSD.org/patches/SA-06:23/openssl.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch  /path/to/patch

c) Recompile the operating system as described in
URL: http://www.freebsd.org/handbook/makeworld.html and reboot the
system.

NOTE: Any third-party applications, including those installed from the
FreeBSD ports collection, which are statically linked to libcrypto(3)
should be recompiled in order to use the corrected code.

NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by
prohibiting the use of exceptionally large public keys.  It is believed
that no existing applications legitimately use such key lengths as would
be affected by this change.

VI.  

Re: Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl

2006-09-28 Thread Colin Percival
Bill Moran wrote:
 Can anyone define exceptionally large as noted in this statement?:
 
 NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by
 prohibiting the use of exceptionally large public keys.  It is believed
 that no existing applications legitimately use such key lengths as would
 be affected by this change.
 
 It would be nice if exceptionally large were replaced with keys in
 excess of x bits in size or something.  I don't expect that this will
 affect me, but ambiguous statements like that make me uncomfortable.

DH and DSA are limited to 1 bits.  RSA is limited to 16400 or 4112 bits
depending upon whether the public exponent is less or more than 72 bits.

I wouldn't have allowed this change into the security branches if I was not
very very confident that no applications would be affected by this.

Colin Percival
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl

2006-09-28 Thread Bill Moran
In response to Colin Percival [EMAIL PROTECTED]:

 Bill Moran wrote:
  Can anyone define exceptionally large as noted in this statement?:
  
  NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by
  prohibiting the use of exceptionally large public keys.  It is believed
  that no existing applications legitimately use such key lengths as would
  be affected by this change.
  
  It would be nice if exceptionally large were replaced with keys in
  excess of x bits in size or something.  I don't expect that this will
  affect me, but ambiguous statements like that make me uncomfortable.
 
 DH and DSA are limited to 1 bits.  RSA is limited to 16400 or 4112 bits
 depending upon whether the public exponent is less or more than 72 bits.
 
 I wouldn't have allowed this change into the security branches if I was not
 very very confident that no applications would be affected by this.
 
 Colin Percival

I'm not questioning your ability to make these decisions, Colin.
Far, far from it.

I'm the type that is made uncomfortable by any statement that reads
_anything_ like don't worry, we've taken care of it.  

Take that email as two separate statements:
1) I'm curious as to exactly how big exceptionally large is.
2) I think this security advisory could be improved by including the
   answer to #1.

Thanks for the quick response, and all the work you do.

-- 
Bill Moran
Collaborative Fusion Inc.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]