Original issue date: December 16, 2002<br> Last revised: May 5, 2003<br> Source: CERT/CC<br> <p> A complete revision history is at the end of this file. </p> <br> <h3>Systems Affected</h3> <ul> <li>Secure shell (SSH) protocol implementations in SSH clients and servers from multiple vendors</li> </ul> <br> <h2>Overview</h2> <p> Multiple vendors' implementations of the secure shell (SSH) transport layer protocol contain vulnerabilities that could allow a remote attacker to execute arbitrary code with the privileges of the SSH process or cause a denial of service. The vulnerabilities affect SSH clients and servers, and they occur before user authentication takes place. </p> <p> Summary vendor information can be found in the <a href="http://www.kb.cert.org/vuls/id/389665#systems"> Systems Affected</a> section of VU#389665. </p> <br> <h2>I. Description</h2> The SSH protocol enables a secure communications channel from a client to a server. From the IETF draft <a href="http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt"><i>SSH Transport Layer Protocol</i></a>: <blockquote><i> The SSH transport layer is a secure low level transport protocol. It provides strong encryption, cryptographic host authentication, and integrity protection.... Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. </blockquote></i> <p> <a href="http://www.rapid7.com/">Rapid7</a> has developed a suite (SSHredder) of test cases that examine the connection initialization, key exchange, and negotiation phase (KEX, KEXINIT) of the SSH transport layer protocol. The suite tests the way an SSH transport layer implementation handles invalid or incorrect packet and string lengths, padding and padding length, malformed strings, and invalid algorithms. <p> The test suite has demonstrated a number of vulnerabilities in different vendors' SSH products. These vulnerabilities include buffer overflows, and they occur before any user authentication takes place. SSHredder was primarily designed to test key exchange and other processes that are specific to version 2 of the SSH protocol; however, certain classes of tests are also applicable to version 1. </p> <p> Further information about this set of vulnerabilities may be found in Vulnerability Note <a href="http://www.kb.cert.org/vuls/id/389665">VU#389665</a>. </p> <p> Rapid7 has published a detailed advisory (<a href="http://www.rapid7.com/advisories/R7-0009.txt">R7-0009</a>) and the <a href="http://www.rapid7.com/perl/DownloadRequest.pl?PackageChoice=666">SSHredder</a> test suite. </p> <p> Common Vulnerabilities and Exposures (<a href="http://cve.mitre.org/">CVE</a>) has assigned the following candidate numbers for several classes of tests performed by SSHredder: <ul> <li><a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1357">CAN-2002-1357</a> - incorrect field lengths</li> <li><a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1358">CAN-2002-1358</a> - lists with empty elements or multiple separators</li> <li><a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1359">CAN-2002-1359</a> - "classic" buffer overflows</li> <li><a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1360">CAN-2002-1360</a> - null characters in strings</li> </ul> </p> <br> <h2>II. Impact</h2> <p> The impact will vary for different vulnerabilities and products, but in severe cases, remote attackers could execute arbitrary code with the privileges of the SSH process. Both SSH clients and servers are affected, since both implement the SSH transport layer protocol. On Microsoft Windows systems, SSH servers commonly run with SYSTEM privileges, and on UNIX systems, SSH daemons typically run with root privileges. In the case of SSH clients, any attacker-supplied code would run with at least the privileges of the user who started the client program. Additional privileges may be afforded to an attacker when the SSH client is setuid or setgid to a more privileged user, such as root. Attackers could also crash a vulnerable SSH process, causing a denial of service. </p> <br> <h2>III. Solution</h2> <h4>Apply a patch or upgrade</H4> <p> Apply the appropriate patch or upgrade as specified by your vendor. See <a href="#vendors">Appendix A.</a> below and the <a href="http://www.kb.cert.org/vuls/id/389665#systems">Systems Affected</a> section of VU#389665 for further information. </p> <h4>Restrict access</h4> <p> Limit access to SSH servers to trusted hosts and networks using firewalls or other packet-filtering systems. Some SSH servers may have the ability to restrict access based on IP addresses, or similar effects may be achieved by using TCP wrappers or other related technology. </p> <p> SSH clients can reduce the risk of attacks by only connecting to trusted servers by IP address. </p> <p> While these workarounds will not prevent exploitation of these vulnerabilities, they will make attacks somewhat more difficult, in part by limiting the number of potential sources of attacks. </p> <br> <a name="vendors"></a> <h2>Appendix A. Vendor Information</h2> <p> This appendix contains information provided by vendors. When vendors report new information, this section is updated and the changes are noted in the revision history. If a vendor is not listed below, we have not received their comments. The <a href="http://www.kb.cert.org/vuls/id/389665#systems"> Systems Affected</a> section of VU#389665 contains additional vendor status information. </p> <a name="alcatel"> <h4><a href="http://www.alcatel.com/">Alcatel</a></h4> <blockquote> <p> Following CERT advisory CA-2002-36 on security vulnerabilities in the SSH implementations, Alcatel has conducted an immediate assessment to determine any impact this may have on our portfolio. A first analysis showed that various Alcatel products were affected: namely the 6600, 7000 and 8000 OmniSwitches running AOS 5.1.3 and for which corrections had been made available to customers. This issue has now been fixed both in a AOS 5.1.3 maintenance release and in AOS 5.1.4. The security of our customers' networks is of highest priority for Alcatel. Therefore we continue to test our product portfolio against potential SSH security vulnerabilities and will provide updates if necessary. </p> </blockquote> <!-- end vendor --> <a name="apple"> <h4><a href="http://www.apple.com/">Apple Computer Inc.</a></h4> <blockquote> <p> Apple: Mac OS X and Mac OS X Server do not contain the vulnerabilities described in this report. </p> </blockquote> <!-- end vendor --> <a name="cisco"> <h4><a href="http://www.cisco.com/">Cisco Systems, Inc.</a></h4> <blockquote> <p> Cisco Systems has several products that are vulnerable to the attacks posed by the SSHredder test suite. Complete details are available at <a href="http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml">http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml</a>. </p> <p> Based on initial testing and evaluation of this vulnerability, earlier versions of this advisory listed Cisco Systems as "Not Vulnerable." Upon additional internal testing it was determined that some Cisco products were indeed vulnerable. </p> </blockquote> <!-- end vendor --> <a name="cray"> <h4><a href="http://www.cray.com/">Cray Inc.</a></h4> <blockquote> <p> Cray Inc. supports the OpenSSH product through their Cray Open Software (COS) package. COS 3.3, available the end of December 2002, is not vulnerable. If a site is concerned, they can contact their local Cray representive to obtain an early copy of the OpenSSH contained in COS 3.3. </p> </blockquote> <!-- end vendor --> <a name="cryptlib"> <h4><a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a></h4> <blockquote> <p> From testing against the SSHredder data the invalid packets are being caught and rejected by cryptlib's packet validity-checking code, making it not vulnerable to the problem. </p> </blockquote> <!-- end vendor --> <a name="fsecure"> <a name="f-secure"> <a name="datafellows"> <h4><a href="http://www.f-secure.com/">F-Secure</a></h4> <blockquote> <p> F-Secure SSH products are not exploitable via these attacks. While F-Secure SSH versions 3.1.0 build 11 and earlier crash on these malicious packets, we did not find ways to exploit this to gain unauthorized access or to run arbitrary code. Furthermore, the crash occurs in a forked process so the denial of service attacks are not possible. </p> </blockquote> <!-- end vendor --> <a name="fujitsu"> <h4><a href="http://www.fujitsu.com/">Fujitsu</a></h4> <blockquote> <p> Fujitsu's UXP/V OS is not vulnerable because it does not support SSH. </p> </blockquote> <!-- end vendor --> <a name="compaq"> <a name="hp"> <h4><a href="http://www.hp.com/">Hewlett-Packard</a></h4> <blockquote> <p> SOURCE: Hewlett-Packard Company<br> <br> HP Tru64 UNIX V5.1a or HP OpenVMS systems using SSH V2.4.1 should upgrade to SSH V3.2.<br> <br> HP has investigated this report and find that our implementations within HP-UX are not vulnerable. </p> </blockquote> <!-- end vendor --> <a name="ibm"> <h4><a href="http://www.ibm.com/">IBM</a></h4> <blockquote> <p> IBM's AIX is not vulnerable to the issues discussed in CERT CA-2002-36. </p> </blockquote> <!-- end vendor --> <a name="juniper"> <h4><a href="http://www.juniper.net/">Juniper Networks</a></h4> <blockquote> <p> Juniper Networks has determined that the software on the ERX router platforms is susceptible to this vulnerability. Patches for all supported releases are now available to resolve the vulnerability. Customers should contact the Juniper Networks Technical Assistance Center to obtain the latest patch. </p> <p> Initial testing of the JUNOS software on Juniper's M-, T-, and J-series routers has not revealed any susceptibility to this vulnerability. Juniper will continue testing, and if any problems are found, corrective action will be taken. </p> <p> The Juniper G-series Cable Modem Termination Systems are not susceptible to this vulnerability. </p> </blockquote> <!-- end vendor --> <a name="lsh"> <h4><a href="http://www.lysator.liu.se/~nisse/lsh/">lsh</a></h4> <blockquote> <p> I've now tried the testsuite with the latest stable release of lsh, lsh-1.4.2. Both the client and the server seem NOT VULNERABLE. </blockquote> <!-- end vendor --> <a name="netscreen"> <h4><a href="http://www.netscreen.com/">NetScreen Technologies Inc.</a></h4> <blockquote> <p> Tested latest versions. Not Vulnerable. </p> </blockquote> <!-- end vendor --> <a name="nortel"> <h4><a href="http://www.nortel.com/">Nortel Networks</a></h4> <blockquote> <p> The following Nortel Networks products are being assessed to determine whether they are potentially affected by the vulnerabilities identified in CERT Advisory CA-2002-36: Shasta Broadband Service Node and Shasta Service Creation System. </p> <p> Passport 8000 Series Software is potentially affected; this issue will be addressed in the next maintenance releases<br> 3.3.2.0, for version 3.3, scheduled for availability January 24th, 2003.<br> 3.2.4, for version 3.2, scheduled for availability in Mid March 2003 (target)<br> Releases before 3.2.1 are not affected.<br> A product bulletin will be issued shortly.<br> </p> <p> STORM is potentially affected; a product bulletin will be issued shortly and this issue will be addressed in the next Maintenance Release scheduled for availability in March, 2003. </p> <p> Other Nortel Networks products implementing SSH are not affected by the vulnerabilities identified in CERT Advisory CA-2002-36. </p> <p> For more information please contact Nortel at:<br> <br> North America: 1-8004NORTEL or 1-800-466-7835<br> Europe, Middle East and Africa: 00800 8008 9009, or +44 (0) 870 907 9009<br> Contacts for other regions are available at <<a href="http://www.nortelnetworks.com/help/contact/global/">http://www.nortelnetworks.com/help/contact/global/</a>><br> </p> </blockquote> <!-- end vendor --> <a name="openssh"> <h4><a href="http://www.openssh.org/">OpenSSH</a></h4> <blockquote> <p> From my testing it seems that the current version of OpenSSH (3.5) is not vulnerable to these problems, and some limited testing shows that no version of OpenSSH is vulnerable. </p> </blockquote> <!-- end vendor --> <a name="pragma"> <h4><a href="http://www.pragmasys.com/">Pragma Systems, Inc.</a></h4> <blockquote> <p> December 16, 2002<br> <br> Rapid 7 and CERT Coordination Center Vulnerability report VU#389665<br> <br> Pragma Systems Inc. of Austin, Texas, USA, was notified regarding a possible vulnerability with Version 2.0 of Pragma SecureShell. Pragma Systems tested Pragma SecureShell 2.0 and the upcoming new Version 3.0, and found that the attacks did cause a memory access protection fault on Microsoft platforms.<br> <br> After research, Pragma Systems corrected the problem. The correction of the problem leads us to believe that any attack would not cause a Denial of Service, or the ability of random code to run on the server.<br> <br> The problem is corrected in Pragma SecureShell Version 3.0. Any customers with concerns regarding this vulnerability report should contact Pragma Systems, Inc at <a href="mailto:support@pragmasys.com">support@pragmasys.com</a> for information on obtaining an upgrade free of charge. Pragma's web site is located at www.pragmasys.com and the company can be reached at 1-512-219-7270. </p> </blockquote> <!-- end vendor --> <a name="putty"> <h4><a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY</a></h4> <blockquote> <p> PuTTY versions 0.53 and earlier are vulnerable to a buffer overrun discovered by SSHredder. Version 0.53b fixes this vulnerability. </p> </blockquote> <!-- end vendor --> <a name="riverstone"> <h4><a href="http://www.riverstonenet.com/">Riverstone Networks</a></h4> <blockquote> <p> Riverstone's implemention of SSH is based on OpenSSH, which is not vulnerable to any of the particular tests that are run by the SSHredder test suite. However, while running the test suite under certain conditions the router can experience a problem causing it to reload. </p> <p> For more details, please see <a href="http://www.riverstonenet.com/support/support_security.shtml">http://www.riverstonenet.com/support/support_security.shtml</a> and the security advisory at <a href="http://www.riverstonenet.com/support/tb0239-9.shtml">http://www.riverstonenet.com/support/tb0239-9.shtml</a>. </p> </blockquote> <!-- end vendor --> <a name="ssh"> <h4><a href="http://www.ssh.com/">SSH Communications Security</a></h4> <blockquote> <p> With SSH Secure Shell the worst case effect of the vulnerability is a denial of service (DoS) for a single child-server (connection). This cannot be exploited to gain access to the host and this does not affect the parent server in any wa nor does it hinder the server's ability to receive new connections - it only affects the child server that is handling connections to the malicious client, or a client application that is connecting to a malicious server. No arbitrary code can be executed. </p> </blockquote> <!-- end vendor --> <a name="sun"> <h4><a href="http://www.sun.com/">Sun Microsystems Inc.</a></h4> <blockquote> <p> The version of Secure Shell (SSH) shipped with Solaris 9 is not affected by the issues described in CERT VU#389665. </p> </blockquote> <!-- end vendor --> <a name="vandyke"> <h4><a href="http://www.vandyke.com/">VanDyke Software</a></h4> <blockquote> <p> From our testing it seems that the current versions of VanDyke's Secure Shell implementations are not vulnerable to these problems, and some limited testing shows that no prior VanDyke Secure Shell implementations are vulnerable. </p> <p> Official Releases Tested:<br> <br> Server: <blockquote> VShell 2.1.1 October 15, 2002 </blockquote> Clients: <blockquote> SecureCRT 4.0.2 December 3, 2002<br> SecureFX 2.1.1 November 7, 2002<br> Entunnel 1.0.1 October 15, 2002 </blockquote> Older Releases Tested:<br> <br> Servers: <blockquote> VShell 2.0.3 May 28, 2002<br> VShell 1.2.4 May 28, 2002 </blockquote> Clients: <blockquote> SecureCRT 3.4.7 November 7, 2002 </blockquote> </p> </blockquote> <!-- end vendor --> <a name="xerox"> <h4><a href="http://www.xerox.com/">Xerox</a></h4> <blockquote> <p> A response to this advisory is available from our web site:<br> <a href="http://www.xerox.com/security/">http://www.xerox.com/security</a>. </p> </blockquote> <!-- end vendor --> <br> <a name="references"></a> <h2>Appendix B. References</h2> <ul> <li>CERT/CC Vulnerability Note: VU#389665 - <a href="http://www.kb.cert.org/vuls/id/389665">http://www.kb.cert.org/vuls/id/389665</a></li> <li>Rapid 7 Advisory: R7-0009 - <a href="http://www.rapid7.com/advisories/R7-0009.txt">http://www.rapid7.com/advisories/R7-0009.txt</a></li> <li>Rapid 7 SSHredder test suite - <a href="http://www.rapid7.com/perl/DownloadRequest.pl?PackageChoice=666">http://www.rapid7.com/perl/DownloadRequest.pl?PackageChoice=666</a></li> <li>IETF Draft: SSH Transport Layer Protocol - <a href="http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt">http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt</a></li> <li>IETF Draft: SSH Protocol Architecture - <a href="http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt">http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt</a></li> <li>Privilege Separated OpenSSH - <a href="http://www.citi.umich.edu/u/provos/ssh/privsep.html">http://www.citi.umich.edu/u/provos/ssh/privsep.html</a></li> </ul> <hr noshade> <p> The CERT Coordination Center thanks <a href="http://www.rapid7.com">Rapid7</a> for researching and reporting these vulnerabilities. </p> <hr noshade> <p> Authors: <a href="mailto:cert@cert.org?subject=CA-2002-36%20VU%23389665%20Feedback">Art Manion</a>. </p> <!--#include virtual="/include/footer_nocopyright.html" --> <p>Copyright 2002 Carnegie Mellon University.</p> <p>Revision History <p> <small> December 16, 2002: Initial release, clarified setuid/setgid SSH client impact, updated IBM statement<br> December 17, 2002: Added VanDyke statement, updated SSH.com statement, removed PuTTY statement, added DoS impact, fixed Pragma link<br> December 18, 2002: Updated Cisco statement, added HP statement<br> December 20, 2002: Updated Cisco statement, added Sun statement, added Apple statement, added vendor information link to Overview<br> January 2, 2003: Added Riverstone statement.<br> January 6, 2003: Added Juniper statement<br> January 7, 2003: (Re-)added PuTTy statement<br> January 9, 2003: Updated Juniper statement<br> January 20, 2003: Added Nortel statement<br> February 25, 2003: Added Alcatel and Xerox statements<br> March 11, 2003: Added cryptlib statement<br> May 5, 2003: Updated Alcatel statement<br> </small> </p> |