FreeBSD Security Advisories
2005-Oct-11 05:03 UTC
FreeBSD Security Advisory FreeBSD-SA-05:21.openssl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
============================================================================FreeBSD-SA-05:21.openssl
Security Advisory
The FreeBSD Project
Topic: Potential SSL 2.0 rollback
Category: contrib
Module: openssl
Announced: 2005-10-11
Credits: Yutaka Oiwa
Affects: All FreeBSD releases.
Corrected: 2005-10-11 11:52:46 UTC (RELENG_6, 6.0-STABLE)
2005-10-11 11:53:03 UTC (RELENG_6_0, 6.0-RELEASE)
2005-10-11 11:52:01 UTC (RELENG_5, 5.4-STABLE)
2005-10-11 11:52:28 UTC (RELENG_5_4, 5.4-RELEASE-p8)
2005-10-11 11:52:13 UTC (RELENG_5_3, 5.3-RELEASE-p23)
2005-10-11 11:50:50 UTC (RELENG_4, 4.11-STABLE)
2005-10-11 11:51:45 UTC (RELENG_4_11, 4.11-RELEASE-p13)
2005-10-11 11:51:20 UTC (RELENG_4_10, 4.10-RELEASE-p19)
CVE Name: CAN-2005-2969
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.
I. Background
The OpenSSL library implements the Secure Sockets Layer and Transport
Layer Security protocols, as well as providing a large number of basic
cryptographic functions.
The Secure Sockets Layer protocol exists in two versions and includes a
mechanism for negotiating the protocol version to be used. If the
protocol is executed correctly, it is impossible for a client and
server both capable of the newer version of the protocol (SSLv3) to end
up using the older version of the protocol (SSLv2).
II. Problem Description
In order to provide bug-for-bug compatibility with Microsoft Internet
Explorer 3.02, a verification step required by the Secure Sockets Layer
protocol can be disabled by using the SSL_OP_MSIE_SSLV2_RSA_PADDING
option in OpenSSL. This option is implied by the frequently-used
SSL_OP_ALL option.
III. Impact
If the SSL_OP_MSIE_SSLV2_RSA_PADDING option is enabled in a server
application using OpenSSL, an attacker who is able to intercept and
tamper with packets transmitted between a client and the server can
cause the protocol version negotiation to result in SSLv2 being used
even when both the client and the server support SSLv3. Due to a
number of weaknesses in the SSLv2 protocol, this may allow the attacker
to read or tamper with the encrypted data being sent.
Applications which do not support SSLv2, have been configured to not
permit the use of SSLv2, or do not use the SSL_OP_MSIE_SSLV2_RSA_PADDING
or SSL_OP_ALL options are not affected.
IV. Workaround
No workaround is available.
V. Solution
NOTE WELL: The solution described below causes OpenSSL to ignore the
SSL_OP_MSIE_SSLV2_RSA_PADDING option and hence to require conformance
with the Secure Sockets Layer protocol. As a result, this solution
will reintroduce incompatibility with Microsoft Internet Explorer 3.02
and any other applications which exhibit the same protocol violation.
Perform one of the following:
1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
RELENG_5_4, RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch
dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.10,
4.11, 5.3, and 5.4 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:21/openssl.patch
# fetch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:21/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/doc/en_US.ISO8859-1/books/handbook/makeworld.html >.
Note that any statically linked applications that are not part of the
base system (i.e. from the Ports Collection or other 3rd-party sources)
must be recompiled.
All affected applications must be restarted for them to use the
corrected library. Though not required, rebooting may be the easiest
way to accomplish this.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/crypto/openssl/crypto/opensslv.h 1.1.1.1.2.11
src/crypto/openssl/ssl/s23_srvr.c 1.2.2.6
RELENG_4_11
src/UPDATING 1.73.2.91.2.14
src/sys/conf/newvers.sh 1.44.2.39.2.17
src/crypto/openssl/crypto/opensslv.h 1.1.1.1.2.10.4.1
src/crypto/openssl/ssl/s23_srvr.c 1.2.2.5.8.1
RELENG_4_10
src/UPDATING 1.73.2.90.2.19
src/sys/conf/newvers.sh 1.44.2.34.2.20
src/crypto/openssl/crypto/opensslv.h 1.1.1.1.2.10.2.1
src/crypto/openssl/ssl/s23_srvr.c 1.2.2.5.6.1
RELENG_5
src/crypto/openssl/crypto/opensslv.h 1.1.1.1.15.2.2
src/crypto/openssl/ssl/s23_srvr.c 1.7.6.1
RELENG_5_4
src/UPDATING 1.342.2.24.2.17
src/sys/conf/newvers.sh 1.62.2.18.2.13
src/crypto/openssl/crypto/opensslv.h 1.1.1.15.2.1.2.1
src/crypto/openssl/ssl/s23_srvr.c 1.7.10.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.26
src/sys/conf/newvers.sh 1.62.2.15.2.28
src/crypto/openssl/crypto/opensslv.h 1.1.1.15.4.1
src/crypto/openssl/ssl/s23_srvr.c 1.7.8.1
RELENG_6
src/crypto/openssl/ssl/s23_srvr.c 1.7.12.1
src/crypto/openssl/crypto/opensslv.h 1.1.1.16.2.1
RELENG_6_0
src/UPDATING 1.73.2.91.2.14
src/crypto/openssl/crypto/opensslv.h 1.1.1.16.4.1
src/crypto/openssl/ssl/s23_srvr.c 1.7.14.1
- -------------------------------------------------------------------------
VII. References
http://www.openssl.org/news/secadv_20051011.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2969
The latest revision of this advisory is available at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:21.openssl.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFDS6g2FdaIBMps37IRAr7CAJ9l7bq6Fy1l1bN2LRUS0bXqi+aKKACfW1Sj
JCNxiTF4GT/oV2EMDnIs0gc=j+YS
-----END PGP SIGNATURE-----
jimmy@inet-solutions.be
2005-Oct-11 06:09 UTC
FreeBSD Security Advisory FreeBSD-SA-05:21.openssl
Quoting FreeBSD Security Advisories <security-advisories@freebsd.org>:> ============================================================================> FreeBSD-SA-05:21.openssl Security Advisory > The FreeBSD Project[..]> > c) Recompile the operating system as described in > <URL: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >.Is there any reason why one would need to compile the whole operating system? I can understand that static linked apps need to be recompiled, but which are there actually any at all (and linked against openssl)? Kind regards, Jimmy Scott ---------------------------------------------------------------- This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to abuse@ihosting.be ----------------------------------------------------------------
Ian G wrote:> FreeBSD Security Advisories wrote: >> Applications which do not support SSLv2, have been configured to not >> permit the use of SSLv2, or do not use the SSL_OP_MSIE_SSLV2_RSA_PADDING >> or SSL_OP_ALL options are not affected. >> >> IV. Workaround >> >> No workaround is available. > > Isn't the workaround obviously to switch off V2?Disabling applications to not permit use of SSLv2 is a workaround. However, this is something which needs to be done on an application-by-application basis, and it is likely that there will be some applications will do not have any option for doing this.> In the phishing world - where users are being > exposed to losses in the billion dollar range > or so - we are crying out for the removal of v2. > Can this be done?SSL is supposed to negotiate the use of SSLv3 if it is supported by both the client and the server, so I don't see why disabling SSLv2 entirely would be useful aside from protecting against this vulnerability. Colin Percival
FreeBSD Security Advisories wrote:> Note that any statically linked applications that are not part of the > base system (i.e. from the Ports Collection or other 3rd-party sources) > must be recompiled.Ok, is there any way to list installed ports which are statically linked against OpenSSL? bye & Thanks av.
--- Peter Jeremy <PeterJeremy@optushome.com.au> wrote:> On Wed, 2005-Oct-12 00:12:35 -0700, Arne W?rner wrote: > >Btw: Why should the string "OpenSSL" be contained in each and > >every executable, that might use OpenSSL? > > OpenSSL has a version string of the form "OpenSSL 0.9.7e 25 Oct > 2004" embedded in it. >As far as I understand static linking, only the symbols that r used r linked into the executable... So: Why should that version string be linked into the executable? Is it a necessary part of the SSL protocol to say the version? -Arne __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
[Trimmed cc: to just the appropriate public mailing list.] On Oct 11, 2005, at 7:25 AM, Ian G wrote:> FreeBSD Security Advisories wrote: > > >> Applications which do not support SSLv2, have been configured to not >> permit the use of SSLv2, or do not use the >> SSL_OP_MSIE_SSLV2_RSA_PADDING >> or SSL_OP_ALL options are not affected. >> IV. Workaround >> No workaround is available. >> > > Isn't the workaround obviously to switch off V2?Yes. Sorry that wasn't mentioned.> SSL v2 should be disabled anyway. In the browser > world we have been actively moving to a position > of not delivering SSL v2 as enabled by default, > and we've been telling people to switch off SSL > v2 for some time in order to flush out any issues. > (none reported that I know of.) > > We *desparately* need this done so that servers > can be switched off SSL v2 so they can deliver > the SSL v3 hello so that we can start to use > virtual hosts. The ability to use more SSL > more frequently feeds into tools that defend > against phishing because they rely on the use > of certificates to cache identity; so this is > actually a highly desirable thing in security > terms. > > In the phishing world - where users are being > exposed to losses in the billion dollar range > or so - we are crying out for the removal of v2. > Can this be done?I agree. The SSLv3 specification was published in 1995 and quickly adopted. Support for SSLv3 seemed pretty much ubiquitous by 1999. SSLv2 has several well-known cryptographic weakness with real impact and should not be used. Summarizing [Rescorla 2000]: * An attacker may interfere with the SSLv2 protocol negotiation in order to force the selection of a weak suite of cryptographic algorithms. (This is the most severe problem for most installations, IMHO) * An attacker may inject a TCP FIN packet into an active SSLv2 session, causing data transfer to terminate. This termination will not be detected by the client or server. * The only message authentication code (MAC) algorithm available for SSLv2 is MD5. There have been several developments that have caused some cryptographers to become concerned about the security of MD5. * SSLv2 uses the same key for encryption and message authentication, so that any successful cryptographic attack is a total break. * A design flaw in SSLv2 client authentication may allow an attacker to hijack a client's credentials. I've been concerned enough to disable SSLv2 in most of my own installations. But now that it is clear that there are downgrade-to- SSLv2 attacks in some versions of OpenSSL (and probably some other SSL/TLS implementations), I'm even more concerned. Cheers, -- Jacques Vidrine <jacques@vidrine.us> [Rescorla 2000] Rescorla, Eric. _SSL and TLS: Designing and Building Secure Systems_. Addison-Wesley, 2000.
> unfortunately, this is the dark side of FreeBSD security patch > management :) and I think also the main reason FreeBSD isn't so widely > deployed into enterprise environments. It's ok for hacking or managing > few boxes but try to imagine how to manage security on hundreds of them > this way. :(> on the other side (bright side :) you can try to use unofficial and > often somewhat slowly updating solutions such as bsdupdate > (www.bsdupdates.com) or freebsd-update (from ports tree).> currently, FreeBSD just don't have a mechanism to handle security > advisories in quick way.> any suggestions/corrections ?> j.You can always designate a build box and NFS share /usr/obj and /usr/src and have the other FreeBSD boxens mount this and then do an install{world/kernel} jimmy at inet-solutions.be wrote:> Quoting FreeBSD Security Advisories <security-advisories at freebsd.org>: > > >>============================================================================>>FreeBSD-SA-05:21.openssl Security Advisory >> The FreeBSD Project > > [..] > >>c) Recompile the operating system as described in >><URL: >>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >. > > > Is there any reason why one would need to compile the whole operating system? > I can understand that static linked apps need to be recompiled, but which > are there actually any at all (and linked against openssl)? > > Kind regards, > Jimmy Scott > > ---------------------------------------------------------------- > This message has been sent through ihosting.be > To report spamming or other unaccepted behavior > by a iHosting customer, please send a message > to abuse at ihosting.be > ---------------------------------------------------------------- > _______________________________________________ > freebsd-security at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org" >cheers mars
Ok, i think the FreeBSD team should isolate all statically linked applications which are part of the operating system and which depend on OpenSSL. They must be re-build (not the whole operating system) in order OpenSSL changes to be applyed to them. Statically linked ports are responsibility of the person who installed them. Vladimir On Wed, 12 Oct 2005 00:53:49 +0200 Andrea Venturoli <ml@netfence.it> wrote:> FreeBSD Security Advisories wrote: > > > Note that any statically linked applications that are not part of the > > base system (i.e. from the Ports Collection or other 3rd-party sources) > > must be recompiled. > > Ok, is there any way to list installed ports which are statically linked > against OpenSSL? > > bye & Thanks > av. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
On Wed, Oct 12, 2005 at 11:14:57AM +0300, Vladimir Terziev wrote:>> Ok, i think the FreeBSD team should isolate all statically linked ? > applications which are part of the operating system and which depend > on OpenSSL. They must be re-build (not the whole operating system) > in order OpenSSL changes to be applyed to them.AFAIK there are no statically linked openssl applications in the FreeBSD base system, unless someone has specifically compiled them that way on their own. Kris P.S. Please wrap your lines at 70 characters so that your emails may be easily read. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20051012/3f78dcc5/attachment.bin
Kris Kennaway wrote:> AFAIK there are no statically linked openssl applications in the > FreeBSD base system, unless someone has specifically compiled them > that way on their own.I can confirm that this is true for 4.10, 4.11, 5.3, and 5.4, at least under the default build flags. Colin Percival
Giorgos Keramidas wrote:> The alternative of manually fiddling with makefiles under /usr/src may > be ok for hacker-style, experimental installations, where a few hours of > breakage may be ok. This is _UNACCEPTABLE_ in a large setup.This is one of the reasons we have continued using OPENSSL_OVERWRITE_BASE="YES" plus WITH_OPENSSL_BASE="YES" and keeping up-to-date via the openssl and openssh ports. These options have saved us a _lot_ of headaches over the years despite the fact that it is has been officially "deprecated" since 4.11 and requires a Makefile hack. *_OVERWRITE_BASE _should_be_a_required_option_ in _all_ ports that are also available as base applications (sendmail/postfix, bind, ...) Either that or move these apps out of the base altogether (as was done with Perl).> Especially if one considers that large setups can make use of network > booting from preinstalled images, which have been asynchronously > updated, for any number of machines, to include the fixes.Large setups can take advantage of many economies of scale that the rest of us cannot. We cannot reboot client servers whenever a kernel or OS patch comes out, much less keep a test machine around for every arch and OS version under support. -- Roger Marquis Roble Systems Consulting http://www.roble.com/