TUCoPS :: BSD :: ciack011.txt

BSD Buffer Overflow ssh rsaref2


                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___

                             INFORMATION BULLETIN

           Buffer Overflow Vulnerabilities in SSH Daemon and RSAREF2

December 21, 1999 17:00 GMT                                       Number K-011
PROBLEM:       A buffer overflow vulnerabilities has been identified in SSH 
               Daemon and RSAREF2 Library. 
PLATFORM:      Systems running some versions of sshd that are vulnerable are: 
                 F-Secure SSH versions prior 1.3.7
                 FreeBSD 3.3R
                 Configuration of NetBSD
                 SSH1 thru SSH1.2.27 
               RSAREF v2.0 
DAMAGE:        A buffer overflow may be exploited to gain root access. 
SOLUTION:      Apply the available patches. 
VULNERABILITY  The risk is HIGH. Buffer overflow attacks are common and easy 
ASSESSMENT:    to execute. 

[  Start CERT Advisory  ]

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
   Additional information about the RSAREF2 vulnerability can be found at
   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
   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
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
          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 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.

   The Microsoft Security Response Team has investigated this issue, and
   no Microsoft products are affected by the vulnerability.

   NetBSD does not ship with ssh in either its US-only or International
   variants at this time, so no default installation of NetBSD is
   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 with RSAREF is not vulnerable.
OpenBSD / OpenSSH

   More information is available from:
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
   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
   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 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
   You can verify this patch with a detached PGP signature from the
   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
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
   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:

[  End CERT Advisory  ]


CIAC wishes to acknowledge the contributions of CERT for the 
information contained in this bulletin.

CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 925-422-8193
    FAX:      +1 925-423-8002
    STU-III:  +1 925-423-2604
    E-mail:   ciac@llnl.gov

For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), use one of the following methods to contact CIAC:

    1.  Call the CIAC voice number 925-422-8193 and leave a message, or

    2.  Call 888-449-8369 to send a Sky Page to the CIAC duty person or

    3.  Send e-mail to 4498369@skytel.com, or

    4.  Call 800-201-9288 for the CIAC Project Leader.

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:      http://www.ciac.org/
                        (or http://ciac.llnl.gov -- they're the same machine)
   Anonymous FTP:       ftp.ciac.org
                        (or ciac.llnl.gov -- they're the same machine)
   Modem access:        +1 (925) 423-4753 (28.8K baud)
                        +1 (925) 423-3331 (28.8K baud)

CIAC has several self-subscribing mailing lists for electronic
1. CIAC-BULLETIN for Advisories, highest priority - time critical
   information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
   (SPI) software updates, new features, distribution and
3. SPI-NOTES, for discussion of problems and solutions regarding the
   use of SPI products.

Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:

E-mail to       ciac-listproc@llnl.gov or majordomo@rumpole.llnl.gov:
        subscribe list-name 
  e.g., subscribe ciac-bulletin 

You will receive an acknowledgment E-mail immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the E-mail.  This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.

If you include the word 'help' in the body of an E-mail to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via E-mail, etc.

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

K-001: Four Vulnerabilities in the Common Desktop Environment
K-002: Microsoft IE 5 Vulnerability - "download behavior"
K-003: Windows NT 4.0 does not delete Unattended Installation File
K-004: Microsoft "Excel SYLK" Vulnerability
K-005: Microsoft "Virtual Machine Verifier" Vulnerability
K-006: Microsoft - Improve TCP Initial Sequence Number Randomness
K-007: Multiple Vulnerabilities in BIND
K-008: ExploreZip (packed) Worm
K-009: Qpopper Buffer Overflow Vulnerability
K-010: Solaris Snoop Buffer Overflow Vulnerability

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH