[TriLUG] somewhat lame: CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Impl ementations (fwd)
Jon Carnes
jonc at nc.rr.com
Mon Dec 16 18:50:51 EST 2002
This cert was one of the lamest I've ever seen. Virtually no versions
of ssh were shown as vulnerable. The appendix tells the true story -
there are two versions of SSH that run on *Windows* that are vulnerable.
The subject should have said: SSH Windows implementations may be
vulnerable.
Jon.
On Mon, 2002-12-16 at 16:33, Roy Vestal wrote:
> Got this at work. openssh isn't affected (see below, but some of you may
> have other systems that may.
>
> --
> ----------------------------------------
> Roy Vestal
> http://www.trilug.org/~rvestal
> rvestal at trilug.org
>
> I'm not a geek, I just play one on TV
>
> ----------------------------------------
>
>
> -----Original Message-----
> From: CERT Advisory [mailto:cert-advisory at cert.org]
> Sent: Monday, December 16, 2002 2:36 PM
> To: cert-advisory at cert.org
> Subject: CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH
> Implementations
>
>
>
>
> -----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 at 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 at 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 at 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-----
>
>
> _______________________________________________
> TriLUG mailing list
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ:
> http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
More information about the TriLUG
mailing list