-----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

   

   http://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

    and Gerardo Richarte

    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-----