Original release date: December 13, 1999<BR>
Last revised: March 3, 2000<BR>
Source: CERT/CC<BR>
<P>A complete revision history is at the end of this file.
<H3>Systems Affected</H3>
<UL>
<LI>Systems running some versions of sshd
<LI>Systems using products that use RSAREF2 (e.g., some SSL-enabled web servers)
</UL>
<H2>I. Description</H2>
<P>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.
<p>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.
<P>Additional information about the RSAREF2 vulnerability can be found
at
<DL><DD>
<A HREF="http://www.core-sdi.com/advisories/buffer%20overflow%20ing.htm">
http://www.core-sdi.com/advisories/buffer%20overflow%20ing.htm</A>
</DL>
<P>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.
<P>Also, only versions of SSH compiled with RSAREF support, via the
<I>--with-rsaref</I> option, are vulnerable to these issues.
<P>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.
<H2>II. Impact</H2>
<P>Using the two vulnerabilities in conjunction allows an intruder to
execute arbitrary code with the privileges of the process running
sshd, typically root.
<P>We are investigating whether vulnerabilities in other products may
expose the vulnerability in RSAREF2, and will update this advisory as
appropriate.
<P>See Appendices A and B for more information that may affect the
impact of this vulnerability.
<H2>III. Solution</H2>
<H4>Apply patch(es) from your product vendor</H4>
<P>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 <A HREF="#rsa">RSA's vendor
statement</A> in Appendix A.
<P>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.
<P>Appendix A contains information provided by vendors for this
advisory. Appendix B contains information regarding tests 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.
<H4>Use a non-vulnerable implementation of the RSA algorithm</H4>
<P>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.
<H2> Appendix A. Vendor Information</H2>
<H4>Compaq Computer Corporation</H4>
<P>(c) Copyright 1998, 1999 Compaq Computer Corporation. All rights reserved.
<DL>SOURCE:<DD>Compaq Computer Corporation<BR>
Compaq Services<BR>
Software Security Response Team USA
</DL>
<P>Compaq's Tru64 UNIX is not vulnerable. Compaq does not ship ssl
<H4>Covalent Technologies</H4>
<P>Covalent Raven SSL module for Apache
<P>The Raven SSL module is not vulnerable to this attack since the SSL
library used does not use the RSAREF library.
<H4>Data Fellows Inc.</H4>
<P>F-Secure SSH versions prior 1.3.7 are vulnerable but F-Secure SSH
2.x and above are not.
<H4>FreeBSD</H4>
<P>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:
<DL><DD>
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
</DL>
<P>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.
<H4>Fujitsu</H4>
<P>Fujitsu's UXP/V operating system does not support secure shell
(SSH). Therefore, it is not vulnerable to this problem.
<H4>Hewlett-Packard Company</H4>
<P>HP does not supply SSH. HP has not conducted compatibility testing
with version 1.2.27 of SSH, when compiled with the option
<I>--with-rsaref</I>. Further, RSAREF2 has not been tested to date.
As far as the investigation to date, HP appears to be not vulnerable.
<H4>IBM Corporation</H4>
<P>IBM AIX does not currently ship the secure shell (ssh) nor do the
base components of AIX ship or link with the RSAREF2 library.
<P>IBM and AIX are registered trademarks of International Business
Machines Corporation.
<H4>Microsoft</H4>
<P>The Microsoft Security Response Team has investigated this issue,
and no Microsoft products are affected by the vulnerability.
<H4>NetBSD</H4>
<P>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.
<P>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.
<P>Installations which used RSAREF2 in compiling ssh are vulnerable,
and we recommend recompiling without RSAREF2 if their local legal
situation permits.
<P>In addition, the following list of software packages in the NetBSD
"packages" system are also dependent on the RSAREF2 library:
<UL>
<LI>archivers/hpack
<LI>security/openssl
<LI>security/pgp2
<LI>security/pgp5
<LI>www/ap-ssl
</UL>
<P>of those, the security/openssl package is itself a library, and the
following packages depend on it:
<UL>
<LI>net/ppp-mppe
<LI>net/speakfreely-crypto
<LI>www/ap-ssl
</UL>
<P>We recommend recompiling and reinstalling these packages without
RSAREF2, if your local legal situation permits.
<H4>Network Associates, Inc.</H4>
<P>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.
<P>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.
<P>Philip Zimmermann<BR>
10 December 1999
<P>[CERT/CC Note: A <A HREF="http://www.cert.org/advisories/CA-99-15/pgp-statement.asc">PGP signed
copy</A> of this information and
<A HREF="http://www.cert.org/advisories/CA-99-15/pgp-details.asc">additional technical details</A> are
available as well.]
<H4>OpenSSL</H4>
OpenSSL with RSAREF is not vulnerable.
<H4>OpenBSD / OpenSSH </H4>
<P>More information is available from:
<DL><DD>
<A HREF="http://www.openbsd.org/errata.html#sslUSA">
http://www.openbsd.org/errata.html#sslUSA</a>
</DL>
<A NAME="rsa">
<H4>RSA Security Inc.</H4>
<P>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.
<P>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.
<P>This advisory only applies to RSAREF, not RSA Security's current
toolkits and products, which were developed independently of RSAREF.
<P>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.)
<H4>SSH Communications</H4>
<P>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.
<P>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.)
<P>Any implementation compiled without an explicitly specified
--with-rsaref is not affected by this problem.
<P>A <A HREF="http://www.cert.org/advisories/CA-99-15/ssh-patch.txt">patch</A> provided by SSH
Communications is available from the CERT/CC web site. This version
of the patch has been <A HREF="http://www.cert.org/advisories/CA-99-15/ssh-patch.txt.asc">signed</A>
by the CERT/CC.
<H4>Stronghold</H4>
<P>Stronghold does not use RSAREF and is unaffected.
<H2>Appendix B. CERT/CC and Other Third-Party Tests</H2>
<H4>RSAREF Patch from Core SDI and the CERT/CC</H4>
<P>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.
<P>CERT/CC has developed a patch for the RSAREF2 vulnerability based
in part on work done by Core SDI. This patch is available at
<DL>
<DD><A HREF="ftp://ftp.core-sdi.com/pub/patches/rsaref2.patch">
ftp://ftp.core-sdi.com/pub/patches/rsaref2.patch</A>
<DD><A HREF="http://www.cert.org/advisories/CA-99-15/rsa-patch.txt">
http://www.cert.org/advisories/CA-99-15/rsa-patch.txt</A>
</DL>
<P>You can verify this patch with a
<A HREF="http://www.cert.org/advisories/CA-99-15/rsa-patch.txt.asc">
detached PGP signature</A> from the CERT/CC.
<P>This patch should be applied to the rsa.c source file that comes
with the RSAREF distribution. Note that there is also an rsa.c source
file that is part of the SSH distribution, and that this patch will
not apply correctly to that file. When in the correct directory (the
RSAREF source directory) the patch can be applied by issuing the
command:
<DL>
<DD>
patch <rsa-patch.txt
</DL>
<P>We believe the patch <I>originally</I> 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.
<H4>Possible vulnerability of ssh clients</H4>
<P>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:
<FONT FACE="Courier New, Courier, mono">
<PRE>
% 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
%
</PRE>
<FONT FACE="Verdana">
<P>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.
<HR NOSHADE>
<P>The CERT Coordination Center would like to thank
Alberto Solino
<<A HREF="mailto:Alberto_Solino@core-sdi.com">Alberto_Solino@core-sdi.com</A>>
and Gerardo Richarte
<<A HREF="mailto:Gerardo_Richarte@core-sdi.com">Gerardo_Richarte@core-sdi.com</A>>
of Core SDI S.A. Seguridad de la informacion, Buenos Aires, Argentina
(<A HREF="http://www.core-sdi.com">http://www.core-sdi.com</A>),
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.
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 1999, 2000 Carnegie Mellon University.</p>
<HR>
Revision History
<PRE>
December 13, 1999: Initial release
March 3, 2000: Clarified how to apply RSAREF patch
</PRE>
|