4583812 1999-12-14  20:42  /428 rader/ Postmaster
Mottagare: Bugtraq (import) <8900>
Ärende: CERT Advisory CA-99.15 - Buffer Overflows in SSH Daemon an 
------------------------------------------------------------
             RSAREF2 Library
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <19991214102048.B28901@underground.org>
Date:         Tue, 14 Dec 1999 10:20:48 -0800
Reply-To: Aleph One <aleph1@UNDERGROUND.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Aleph One <aleph1@UNDERGROUND.ORG>
X-To:         bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

-----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-----
(4583812) ------------------------------------------(Ombruten)