TUCoPS :: Unix :: General :: ca-9915.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
CERT Advisory CA-99-15 Buffer Overflows in SSH Daemon and RSAREF2 Library
 Original release date: December 13, 1999
 Last revised: --
 Source: CERT/CC
 
 A complete revision history is at the end of this file.
 
Systems Affected
 * Systems running some versions of sshd
 * Systems using products that use RSAREF2 (e.g., some SSL-enabled
 web servers)
 
I. Description
 Some versions of sshd are vulnerable to a buffer overflow that can
 allow an intruder to influence certain variables internal to the
 program. This vulnerability alone does not allow an intruder to
 execute code.
 
 However, a vulnerability in RSAREF2, which was discovered and
 researched by Core SDI, can be used in conjunction with the
 vulnerability in sshd to allow a remote intruder to execute arbitrary
 code.
 
 Additional information about the RSAREF2 vulnerability can be found at
 
 http://www.core-sdi.com/advisories/buffer%20overflow%20ing.htm
 
 The RSAREF2 library was developed from a different code base than
 other implementations of the RSA algorithm, including those from RSA
 Security Inc. The vulnerability described in this advisory is specific
 to the RSAREF2 library and does not imply any weakness in other
 implementations of the RSA algorithm or the algorithm itself.
 
 Also, only versions of SSH compiled with RSAREF support, via the
 --with-rsaref option, are vulnerable to these issues.
 
 The use of the RSAREF2 library in other products may present
 additional vulnerabilities. RSAREF2 may be used in products such as
 SSL-enabled web servers, ssh clients, or other cryptographically
 enhanced products. Appendix A of this advisory will be updated with
 new information as it becomes available regarding problems in other
 products that use the RSAREF2 library.
 
II. Impact
 Using the two vulnerabilities in conjunction allows an intruder to
 execute arbitrary code with the privileges of the process running
 sshd, typically root.
 
 We are investigating whether vulnerabilities in other products may
 expose the vulnerability in RSAREF2, and will update this advisory as
 appropriate.
 
 See Appendices A and B for more information that may affect the impact
 of this vulnerability.
 
III. Solution
Apply patch(es) from your product vendor
 Apply patch(es) to the RSAREF2 library. RSA Security Inc. holds a
 patent on the RSA algorithm and a copyright on the RSAREF2
 implementation. We encourage you to consult your legal counsel
 regarding the legality of any fixes you are considering before
 implementing those fixes. Please see RSA's vendor statement in
 Appendix A.
 
 Exploiting the vulnerability in RSAREF2 requires an application
 program to call the RSAREF2 library with malicious input. For products
 that allow an intruder to influence the data provided to the RSAREF2
 library, you may be able to protect against attacks by validating the
 data they provide to RSAREF2.
 
 Appendix A contains information provided by vendors for this advisory.
 Appendix B contains information regarding test performed by the CERT
 Coordination Center and other people, and advice based on those tests.
 We will update the appendices as we receive or develop more
 information. If you do not see your vendor's name in Appendix A, the
 CERT/CC did not hear from that vendor. Please contact your vendor
 directly.
 
Use a non-vulnerable implementation of the RSA algorithm
 Sites not restricted by patent law may choose to use a non-vulnerable
 implementation of RSA. Since RSA Security Inc. holds a patent on the
 RSA algorithm, this option may not be legally available to you. Please
 consult your legal counsel for guidance on this issue.
 
Appendix A. Vendor Information
Compaq Computer Corporation
 (c) Copyright 1998, 1999 Compaq Computer Corporation. All rights
 reserved.
 
 SOURCE:
 Compaq Computer Corporation
 Compaq Services
 Software Security Response Team USA
 
 Compaq's Tru64 UNIX is not vulnerable. Compaq does not ship ssl
 
Covalent Technologies
 Covalent Raven SSL module for Apache
 
 The Raven SSL module is not vulnerable to this attack since the SSL
 library used does not use the RSAREF library.
 
Data Fellows Inc.
 F-Secure SSH versions prior 1.3.7 are vulnerable but F-Secure SSH 2.x
 and above are not.
 
FreeBSD
 FreeBSD 3.3R and prior releases contain packages with this problem.
 This problem was corrected December 2, 1999 in the ports tree.
 Packages built after this date with the rsaref updated should be
 unaffected by this vulnerabilities. Some or all of the following ports
 may be affected should be rebuilt:
 
 p5-Penguin, p5-Penguin-Easy, jp-pgp, ja-w3m-ssl, ko-pgp, pgpsendmail,
 pine4-ssl, premail, ParMetis, SSLtelnet, mpich, pipsecd, tund,
 nntpcache, p5-Gateway, p5-News-Article, ru-pgp, bjorb, keynote,
 OpenSSH, openssl, p5-PGP, p5-PGP-Sign, pgp, slush, ssh,
 sslproxy, stunnel, apache+mod_ssl, apache+ssl, lynx-ssl,
 w3m-ssl, zope
 
 Please see the FreeBSD Handbook for information on how to obtain a
 current copy of the ports tree and how to rebuild those ports which
 depend on rsaref.
 
Hewlett-Packard Company
 HP does not supply SSH. HP has not conducted compatibility testing
 with version 1.2.27 of SSH, when compiled with the option
 --with-rsaref. Further, RSAREF2 has not been tested to date. As far
 as the investigation to date, HP appears to be not vulnerable.
 
IBM Corporation
 IBM AIX does not currently ship the secure shell (ssh) nor do the base
 components of AIX ship or link with the RSAREF2 library.
 
 IBM and AIX are registered trademarks of International Business
 Machines Corporation.
 
Microsoft
 The Microsoft Security Response Team has investigated this issue, and
 no Microsoft products are affected by the vulnerability.
 
NetBSD
 NetBSD does not ship with ssh in either its US-only or International
 variants at this time, so no default installation of NetBSD is
 vulnerable.
 
 However, ssh is installed and widely used by many NetBSD
 installations, and is available from our software package tree in
 source form. The NetBSD ssh package can be compiled either with or
 without RSAREF2, settable by the administrator at compile time
 according to local copyright and license restrictions.
 
 Installations which used RSAREF2 in compiling ssh are vulnerable, and
 we recommend recompiling without RSAREF2 if their local legal
 situation permits.
 
 In addition, the following list of software packages in the NetBSD
 "packages" system are also dependent on the RSAREF2 library:
 * archivers/hpack
 * security/openssl
 * security/pgp2
 * security/pgp5
 * www/ap-ssl
 
 of those, the security/openssl package is itself a library, and the
 following packages depend on it:
 * net/ppp-mppe
 * net/speakfreely-crypto
 * www/ap-ssl
 
 We recommend recompiling and reinstalling these packages without
 RSAREF2, if your local legal situation permits.
 
Network Associates, Inc.
 After a technical review of the buffer overflow bug in RSAREF, we have
 determined at Network Associates that PGP is not affected by this bug,
 because of the careful way that PGP uses RSAREF.
 
 This applies to all versions of PGP ever released by MIT, which are
 the only versions of PGP that use RSAREF. All other versions of PGP,
 such as the commercial versions and the international versions, avoid
 the use of RSAREF entirely.
 
 Philip Zimmermann
 10 December 1999
 
 [CERT/CC Note: A PGP signed copy of this information and additional
 technical details are available as well.]
 
OpenSSL
 OpenSSL with RSAREF is not vulnerable.
 
OpenBSD / OpenSSH
 More information is available from:
 
 http://www.openbsd.org/errata.html#sslUSA
 
RSA Security Inc.
 RSA Security Inc. recommends that developers implement the proposed or
 similar patch to RSAREF version 2.0 or otherwise to ensure that the
 length in bits of the modulus supplied to RSAREF is less than or equal
 to MAX_RSA_MODULUS_BITS.
 
 RSA Security Inc. is no longer distributing the RSAREF toolkit, which
 it offered through RSA Laboratories in the mid-1990s as a free, source
 implementation of modern cryptographic algorithms. Under the terms of
 the RSAREF license, changes to the RSAREF code other than porting or
 performance improvement require written consent. RSA Security hereby
 gives its consent to implement a patch to RSAREF to address this
 advisory.
 
 This advisory only applies to RSAREF, not RSA Security's current
 toolkits and products, which were developed independently of RSAREF.
 
 Although RSA Security is no longer distributing RSAREF, the toolkit is
 still available in a number of "freeware" products such as SSH under
 RSA Security's original RSAREF v2.0 software license ("license.txt",
 March 25, 1994), which is distributed along with those products. As a
 reminder, that license limits the use of RSAREF to noncommercial
 purposes. RSAREF, RSAREF applications, and services based on RSAREF
 applications may not be sold, licensed or otherwise transferred for
 value. (There is a minor exception for small "shareware" deployments
 as noted in the "info.txt" file, March 25, 1994.)
 
SSH Communications
 The bug only affects ssh when it is compiled with RSAREF (i.e., only
 when --with-rsaref is explicitly supplied on the command line). Any
 version compiled without --with-rsaref is not affected. The problem
 should not affect users of the commercial versions (who are licensed
 to use the built-in RSA) or users outside the United States (who are
 presumably not using RSAREF and can use the built-in RSA without
 needing a license). I.e., only those non-commercial users who actually
 compile with a separately obtained RSAREF should be affected.
 
 The bug is present in all versions of SSH1, up to and including
 1.2.27. It will be fixed in ssh-1-2.28 (expected to go out in a few
 days to fix this problem). It does not affect SSH2. (Please note that
 ssh1 is no longer maintained, except for security fixes, due to
 certain rather fundamental problems that have been fixed in ssh2.)
 
 Any implementation compiled without an explicitly specified
 --with-rsaref is not affected by this problem.
 
 A patch provided by SSH Communications is available from the CERT/CC
 web site. This version of the patch has been signed by the CERT/CC.
 
Stronghold
 Stronghold does not use RSAREF and is unaffected.
 
Appendix B. CERT/CC and Other Third-Party Tests
RSAREF Patch from Core SDI and the CERT/CC
 With the assistance of Core SDI, the CERT Coordination Center tested
 sshd version 1.2.27 running on an Intel-based RedHat Linux system and
 found that configuration to be vulnerable. Tests conducted by Core SDI
 indicate that sshd 1.2.27 running on OpenBSD and FreeBSD on Intel is
 also vulnerable, and it is likely that other configurations are
 vulnerable as well.
 
 CERT/CC has developed a patch for the RSAREF2 vulnerability based in
 part on work done by Core SDI. This patch is available at
 
 ftp://ftp.core-sdi.com/pub/patches/rsaref2.patch
 http://www.cert.org/advisories/CA-99-15/rsa-patch.txt
 
 You can verify this patch with a detached PGP signature from the
 CERT/CC.
 
 We believe the patch originally provided by Core SDI in their advisory
 may not be a complete fix to this particular problem. We have worked
 with them to develop an updated patch and gratefully acknowledge their
 contribution to the fix provided here. Neither the CERT/CC, the
 Software Engineering Institute, nor Carnegie Mellon University
 provides any warranties regarding this patch. Please see our
 disclaimer at the end of this advisory.
 
Possible vulnerability of ssh clients
 The possible vulnerability of ssh clients is of particular concern. As
 we learn more regarding the vulnerability of ssh clients, we will
 update this advisory. One possible way to attack an ssh client would
 be to construct a malicious ssh server and lure or trick victims into
 connecting to the server. The ssh client will warn users when it
 connects to a site that presents a key that does not match one
 previously associated with the server. The dialog may be similar to
 the following:
% ssh badhost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.
Add correct host key in /etc/.ssh/known_hosts to get rid of this message.
Are you sure you want to continue connecting (yes/no)? no
%
 If you see this warning, you should answer "no" to the prompt and
 investigate why the key you received does not match the key you
 expected.
 _________________________________________________________________
 
 The CERT Coordination Center would like to thank Alberto Solino
 <Alberto_Solino@core-sdi.com> and Gerardo Richarte
 <Gerardo_Richarte@core-sdi.com> of Core SDI S.A. Seguridad de la
 informacion, Buenos Aires, Argentina (http://www.core-sdi.com), who
 discovered the problem in RSAREF2 and provided valuable technical
 assistance. We would also like to thank Andrew Cormack of JANET CERT,
 who provided technical assistance; Theo de Raadt of the OpenBSD
 project, who provided valuable feedback used in the construction of
 this advisory; Burt Kaliski of RSA Security Inc.; and Tatu Ylonen of
 SSH Communications Security.
 ______________________________________________________________________
 
 This document is available from:
 http://www.cert.org/advisories/CA-99-15-RSAREF2.html
 ______________________________________________________________________
 
CERT/CC Contact Information
 Email: cert@cert.org
 Phone: +1 412-268-7090 (24-hour hotline)
 Fax: +1 412-268-6989
 Postal address:
 CERT Coordination Center
 Software Engineering Institute
 Carnegie Mellon University
 Pittsburgh PA 15213-3890
 U.S.A.
 
 CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
 Monday through Friday; they are on call for emergencies during other
 hours, on U.S. holidays, and on weekends.
 
Using encryption
 We strongly urge you to encrypt sensitive information sent by email.
 Our public PGP key is available from
 
 http://www.cert.org/CERT_PGP.key
 
 If you prefer to use DES, please call the CERT hotline for more
 information.
 
Getting security information
 CERT publications and other security information are available from
 our web site
 
 http://www.cert.org/
 
 To be added to our mailing list for advisories and bulletins, send
 email to cert-advisory-request@cert.org and include SUBSCRIBE
 your-email-address in the subject of your message.
 
 Copyright 1999 Carnegie Mellon University.
 Conditions for use, disclaimers, and sponsorship information can be
 found in
 
 http://www.cert.org/legal_stuff.html
 
 * "CERT" and "CERT Coordination Center" are registered in the U.S.
 Patent and Trademark Office.
 ______________________________________________________________________
 
 NO WARRANTY
 Any material furnished by Carnegie Mellon University and the Software
 Engineering Institute is furnished on an "as is" basis. Carnegie
 Mellon University makes no warranties of any kind, either expressed or
 implied as to any matter including, but not limited to, warranty of
 fitness for a particular purpose or merchantability, exclusivity or
 results obtained from use of the material. Carnegie Mellon University
 does not make any warranty of any kind with respect to freedom from
 patent, trademark, or copyright infringement.
 _________________________________________________________________
 
 Revision History
December 13, 1999: Initial release
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBOFV9alr9kb5qlZHQEQI7bACg1xlZVHntIvhRHjU1f8BaNVGJlbkAnA6Y
kOuU3ddTO9uguGEv0EuR9Rw3
=IqXt
-----END PGP SIGNATURE-----