Fwd: CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Implementations

From: Muhammad Faisal Rauf Danka (mfrd@attitudex.com)
Date: 12/17/02

  • Next message: rich@annexia.org: "export LD_LIBRARY_PATH in /etc/profile.d/* files"
    Date: Tue, 17 Dec 2002 00:06:47 -0800 (PST)
    From: Muhammad Faisal Rauf Danka <mfrd@attitudex.com>
    To: bugtraq@securityfocus.com
    
    
    ('binary' encoding is not supported, stored as-is)
    
    

    *** There is an attachment in this mail. ***

    _____________________________________________________________
    ---------------------------
    [ATTITUDEX.COM]
    http://www.attitudex.com/
    ---------------------------

    _____________________________________________________________
    Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

    
    

    attached mail follows:


    ('binary' encoding is not supported, stored as-is)
    Date: Mon, 16 Dec 2002 14:37:14 -0500
    From: CERT Advisory <cert-advisory@cert.org>
    To: cert-advisory@cert.org
    
    

    -----BEGIN PGP SIGNED MESSAGE-----

    CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Implementations

       Original issue date: December 16, 2002
       Last revised: --
       Source: CERT/CC

       A complete revision history is at the end of this file.

    Systems Affected

         * Secure shell (SSH) protocol implementations in SSH clients and
           servers from multiple vendors

    Overview

       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.

    I. Description

       The SSH protocol enables a secure communications channel from a client
       to a server. From the IETF draft SSH Transport Layer Protocol:

         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.

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

       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.

       Further information about this set of vulnerabilities may be found in
       Vulnerability Note VU#389665.

       Rapid7 has published a detailed advisory (R7-0009) and the SSHredder
       test suite.

       Common Vulnerabilities and Exposures (CVE) has assigned the following
       candidate numbers for several classes of tests performed by SSHredder:

         * CAN-2002-1357 - incorrect field lengths
         * CAN-2002-1358 - lists with empty elements or multiple separators
         * CAN-2002-1359 - "classic" buffer overflows
         * CAN-2002-1360 - null characters in strings

    II. Impact

       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 servers and clients 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 the privileges of the user who started the client
       program, with the possible exception of SSH clients that may be
       configured with an effective user ID of root (setuid root). Attackers
       could also crash a vulnerable SSH process, causing a denial of
       service.

    III. Solution

    Apply a patch or upgrade

       Apply the appropriate patch or upgrade as specified by your vendor.
       See Appendix A below and the Systems Affected section of VU#389665 for
       specific information.

    Restrict access

       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.

       SSH clients can reduce the risk of attacks by only connecting to
       trusted servers by IP address.

       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.

    Appendix A. Vendor Information

       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 Systems Affected section of
       VU#389665 contains additional vendor status information.

    Cisco Systems, Inc.

         The official statement regarding this is that we are not
         vulnerable.

    Cray Inc.

         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.

    F-Secure

         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.

    Fujitsu

         Fujitsu's UXP/V OS is not vulnerable because it does not support
         SSH.

    IBM

         IBM's AIX is not vulnerabible to the issues discussed in CERT
         Vulnerability Note VU#389665.

    lsh

         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.

    NetScreen Technologies Inc.

         Tested latest versions. Not Vulnerable.

    OpenSSH

         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.

    Pragma Systems, Inc.

         December 16, 2002

         Rapid 7 and CERT Coordination Center Vulnerability report VU#389665

         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.

         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.

         The problem is corrected in Pragma SecureShell Version 3.0. Any
         customers with concerns regarding this vulnerability report should
         contact Pragma Systems, Inc at support@pragmasys.com 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.

    PuTTY

         PuTTY 0.53b addresses vulnerabilities discovered by SSHredder.

    SSH Communications Security

         SSH Secure Shell products are not exploitable via these attacks.

    Appendix B. References

         * CERT/CC Vulnerability Note: VU#389665 -
           http://www.kb.cert.org/vuls/id/389665
         * Rapid 7 Advisory: R7-0009 -
           http://www.rapid7.com/advisories/R7-0009.txt
         * Rapid 7 SSHredder test suite -
           http://www.rapid7.com/perl/DownloadRequest.pl?PackageChoice=666
         * IETF Draft: SSH Transport Layer Protocol -
           http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.
           txt
         * IETF Draft: SSH Protocol Architecture -
           http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-
           13.txt
         * Privilege Separated OpenSSH -
           http://www.citi.umich.edu/u/provos/ssh/privsep.html

         _________________________________________________________________

       The CERT Coordination Center thanks Rapid7 for researching and
       reporting these vulnerabilities.
         _________________________________________________________________

       Author: Art Manion.
       ______________________________________________________________________

       This document is available from:
       http://www.cert.org/advisories/CA-2002-36.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/CC personnel answer the hotline 08:00-17: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 subscribe to the CERT mailing list for advisories and bulletins,
       send email to majordomo@cert.org. Please include in the body of your
       message

       subscribe cert-advisory

       * "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.
         _________________________________________________________________

       Conditions for use, disclaimers, and sponsorship information

       Copyright 2002 Carnegie Mellon University.

       Revision History

       December 16, 2002: Initial release

    -----BEGIN PGP SIGNATURE-----
    Version: PGP 6.5.8

    iQCVAwUBPf4qimjtSoHZUTs5AQEGbAQAiJcA+QFf2mOElaPIFwEmSRC83xlKifq/
    PlmaGbUx2UnwTIi8s2ETF8KjlfQjjgO20B4ms1MMaJ/heyxklOgpeBOQ2mpa2Tnd
    yIY7sxpBuRjF1qS6yQ8/OrcsSqVxdxZWkPLAypV11WcJlMmSxxLdKi5t86EsWic3
    xazIo8XEipc=
    =Nj+0
    -----END PGP SIGNATURE-----



    Relevant Pages

    • CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Implementations
      ... Multiple vendors' implementations of the secure shell (SSH) transport ... The vulnerabilities affect SSH ... SSH clients can reduce the risk of attacks by only connecting to ...
      (Cert)
    • Re: ICSA Labs Network IPS Testing
      ... Having some experience in developing and testing IPS, ... ICSA, to their credit, say that of all the vulnerabilities they will ... those that they (and other vendors) think will affect enterprises. ... IPS is secure from remote attacks. ...
      (Focus-IDS)
    • Re: [SLE] stopping dictionary attacks on sshd (a tcp_wrappers problem)
      ... ssh login does not work when one has just booted, until jifie gets 0 and starts incrementing, then it works. ... We need open ssh connections from the outside. ... We want to defend against these attacks in a reasonable way. ... logsurfer is used because I don't know a better log watching and event ...
      (SuSE)
    • RE: Deliberately create slow SSH response?
      ... Asunto: RE: Deliberately create slow SSH response? ... The brute force attacks are most likely automated, ... Have you thought about limiting access to the service to only certain IPs? ...
      (SSH)
    • CERT Advisory CA-2001-35 Recent Activity Against Secure Shell Daemons
      ... Systems running implementations of the Secure Shell (SSH) protocol ... There are multiple vulnerabilities in several implementations of the ... The CRC32 attack detection code integer overflow vulnerability, ...
      (Cert)