[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: SNI-23: SSH - Vulnerability in ssh-agent




Thought you might want to see this


-----Original Message-----
From: Secure Networks Inc. <sni@SECURENETWORKS.COM>
To: BUGTRAQ@NETSPACE.ORG <BUGTRAQ@NETSPACE.ORG>
Date: Wednesday, January 21, 1998 12:44 AM
Subject: SNI-23: SSH - Vulnerability in ssh-agent


>-----BEGIN PGP SIGNED MESSAGE-----
>
>                        ######    ##   ##    ######
>                        ##        ###  ##      ##
>                        ######    ## # ##      ##
>                            ##    ##  ###      ##
>                        ###### .  ##   ## .  ######.
>
>                            Secure Networks Inc.
>
>                             Security Advisory
>                              January 20, 1998
>
>                          Vulnerability in ssh-agent
>
>
>This advisory details a vulnerabily in the SSH cryptographic login
>program.  The vulnerability enables users to use RSA credentials
>belonging to other users who use the ssh-agent program.  This
>vulnerability may allow an attacker on the same local host to login
>to a remote server as the user utilizing SSH.
>
>
>Problem Description:
>~~~~~~~~~~~~~~~~~~~~
>
>In order to avoid forcing users of RSA based authentication to go
>through the trouble of retyping their pass phrase every time they wish
>to use ssh, slogin, or scp, the SSH package includes a program called
>ssh-agent, which manages RSA keys for the SSH program.  The ssh-agent
>program creates a mode 700 directory in /tmp, and then creates an
>AF_UNIX socket in that directory.  Later, the user runs the ssh-add
>program, which adds his private key to the set of keys managed by the
>ssh-agent program.  When the user wishes to access a service which
>permits him to log in using only his RSA key, the SSH client connects
>to the AF_UNIX socket, and asks the ssh-agent program for the key.
>
>Unfortunately, when connecting to the AF_UNIX socket, the SSH client is
>running as super-user, and performs insufficient permissions checking.
>This makes it possible for users to trick their SSH clients into using
>credentials belonging to other users.  The end result is that any user
>who utilizes RSA authentication AND uses ssh-agent, is vulnerable.
>Attackers can utilize this vulnerability to access remote accounts
>belonging to the ssh-agent user.
>
>
>Technical Details
>~~~~~~~~~~~~~~~~~
>
>When communicating with the ssh-agent program, the SSH program issues a
>connect() system call as super-user to access the AF_UNIX socket.  By
>utilizing symbolic links, an attacker can cause the SSH program to
>connect to an alternate user's AF_UNIX socket, and read their RSA
>credentials.  After the credentials have been read, SSH will use these
>credentials to logon to the remote system as the victim.
>
>
>Vulnerable Systems:
>~~~~~~~~~~~~~~~~~~~
>
>This vulnerability effects the Unix versions of SSH ONLY.
>
>SSH for unix versions 1.2.17 through 1.2.21 are vulnerable if installed
>with default permissions.  Versions of SSH prior to 1.2.17 are subject to
>a similar (but different) attack.
>
>F-Secure SSH for Unix systems prior to release 1.3.3 ARE vulnerable.
>
>You can determine the version of SSH you are running by issuing the case
>sensitive command:
>
>% ssh -V
>
>Version 1.1 of the windows-based SSH client sold by Data Fellows Inc.
>under the F-Secure brand name is NOT vulnerable to this attack.
>
>Versions 1.0 and 1.0a of Mac SSH are NOT vulnerable to this attack.
>
>
>Fix Resolution:
>~~~~~~~~~~~~~~~
>
>Non-commercial users:
>
>If using the free non-commercial SSH distribution for Unix, administrators
>are urged to upgrade to SSH 1.2.22 or later.  Updated versions of the free
>unix SSH can be found at ftp://ftp.cs.hut.fi/pub/ssh
>
>
>Commercial users:
>
>F-Secure SSH version 1.3.3 fixes this security problem.  If you are using
>the commercial Data Fellows SSH package and you have a support contract,
>you can obtain SSH version 1.3.3 from your local retailer.
>
>Users without a support contract can obtain a diff file which fixes
>this problem.  This file can be obtained from:
>
>http://www.DataFellows.com/f-secure/support/ssh/bug/su132patch.html
>
>
>Workaround:
>
>As a temporary workaround, administrators may remove the setuid bit from
>the SSH binary.  This will prevent the attack from working, but will
>disable a form of authentication documented as rhosts-RSA.  For example,
>if your SSH binary is in the /usr/local/bin directory, the following
>command will remove the setuid bit from the SSH binary:
>
># chmod u-s /usr/local/bin/ssh
>
>
>Additional Information
>~~~~~~~~~~~~~~~~~~~~~~
>
>SSH is a cryptographic rsh, rlogin, and rcp replacement.  SSH was
>written by Tatu Ylonen <ylo@cs.hut.fi>.  For more information about the
>noncommercial unix version of SSH, please see http://www.cs.hut.fi/ssh
>
>Commercial versions of ssh are marketed by Data Fellows Inc.  For
>information about the F-secure ssh derivatives sold by Data Fellows Inc,
>please see http://www.DataFellows.com/f-secure
>
>This vulnerability was discovered by David Sacerdote <davids@secnet.com>.
>
>For more information regarding this advisory, contact Secure Networks
>Inc. as <sni@secnet.com>.  A PGP public key is provided below if
>privacy is required.
>
>Type Bits/KeyID    Date       User ID
>pub  1024/9E55000D 1997/01/13 Secure Networks Inc. <sni@secnet.com>
>                              Secure Networks <security@secnet.com>
>
>- -----BEGIN PGP PUBLIC KEY BLOCK-----
>Version: 2.6.3ia
>
>mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5
>uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa
>rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR
>tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd
>EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz
>ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU
>uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J
>AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz
>9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj
>HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha
>OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B
>fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY
>FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA
>8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l
>dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA
>X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s
>cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O
>gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq
>aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5
>ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV
>ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt
>UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl
>OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL
>FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8
>=DchE
>- -----END PGP PUBLIC KEY BLOCK-----
>
>
>Copyright Notice
>~~~~~~~~~~~~~~~~
>The contents of this advisory are Copyright (C) 1997 Secure Networks
>Inc, and may be distributed freely provided that no fee is charged for
>distribution, and that proper credit is given.
>
> You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers
> and advisories at ftp://ftp.secnet.com/advisories
>
> You can browse our web site at http://www.secnet.com
>
> You can subscribe to our security advisory mailing list by sending mail
> to majordomo@secnet.com with the line "subscribe sni-advisories"
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3ia
>Charset: noconv
>
>iQCVAwUBNMUgALgIhFKeVQANAQH25AP+IsM09N1MXI6z8gA6nWNwmrvT2Bf+m/Fq
>k+CKeXdpTO+7YDKXXDtLquOEOYnZpKl+UZr0xGcVX1v01uddGHowADQlApEeajPJ
>rftuKMK7SL2WJ3Iv2olhHotqEuFgmKw1Xu6KLxmANssGbuQvRgdI+Zr7Nt4irpcQ
>BredVG8qNcY=
>=f6CF
>-----END PGP SIGNATURE-----


--
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.