[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
- read forum
- new topic
- search

- meetings list
- recent additions
- add your info
 top 100 sites
- visit top sites
- sign up now
- members

- add your url
- add domain
- search box
- link to us

- our projects
- free email
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Vulnerability in ssh-agent

Title: Vulnerability in ssh-agent
Released by: CERT
Date: 22nd January 1998
Printable version: Click here

Hash: SHA1


CERT* Advisory CA-98.03

Original issue date: Jan. 22, 1998

Last revised: March 2, 1998  Updates section - described two cases in which

                             the vulnerability is present.

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

Topic:  Vulnerability in ssh-agent

- -----------------------------------------------------------------------------

   The text of this advisory was originally released on January 20, 1998,

   as SNI-23, developed by Secure Networks, Inc. (SNI). To more widely

   broadcast this information, we are reprinting the SNI advisory here with

   their permission. Some technical details in the original advisory are

   not included in this reprint, and these are indicated thus:


   We have also removed SNI's PGP public key block and added our contact


   The original advisory is available from


   We will update this advisory as we receive additional information.

   Look for it in an "Updates" section at the end of the advisory.


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.


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 http://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:



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


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 http://ftp.secnet.com/pub/papers

 and advisories at http://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"


- ----------------------------------------------------------------------------

The CERT Coordination Center thanks Secure Networks, Inc. for permission to

reproduce technical content from their advisory SNI-23, which is copyrighted

1997 Secure Networks, Inc.

- ----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT

Coordination Center or your representative in the Forum of Incident Response

and Security Teams (see http://www.first.org/team-info/)

CERT/CC Contact Information

- ----------------------------

Email    cert@cert.org

Phone    +1 412-268-7090 (24-hour hotline)

                CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)

                and are on call for emergencies during other hours.

Fax      +1 412-268-6989

Postal address

         CERT Coordination Center

         Software Engineering Institute

         Carnegie Mellon University

         Pittsburgh PA 15213-3890


Using encryption

   We strongly urge you to encrypt sensitive information sent by email. We can

   support a shared DES key or PGP. Contact the CERT/CC for more information.

   Location of CERT PGP key


Getting security information

   CERT publications and other security information are available from



   CERT advisories and bulletins are also posted on the USENET newsgroup


   To be added to our mailing list for advisories and bulletins, send

   email to


   In the subject line, type

        SUBSCRIBE  your-email-address

- ---------------------------------------------------------------------------

Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,

and sponsorship information can be found in

http://www.cert.org/legal_stuff.html and http://ftp.cert.org/pub/legal_stuff .

If you do not have FTP or web access, send mail to cert@cert.org with

"copyright" in the subject line.

*CERT is registered in the U.S. Patent and Trademark Office.

- ---------------------------------------------------------------------------

This file: http://info.cert.org/pub/cert_advisories/CA-98.03.ssh-agent


               click on "CERT Advisories"



(added March 2, 1998)

Readers should note that the vulnerability is present in two distinct cases:

        1. On machines where the ssh-agent is running (the ssh client), as

           described above. The solution is described in the body of this


        2. On the remote machine that the user logs into using ssh. This case

           arises when the user logs into the sshd server via ssh with agent

           forwarding enabled on the client machine and when the server is

           using a version of SSH earlier than 1.2.22. Until remote sites have

           upgraded to SSH 1.2.22 or later, we strongly encourage users to

           ensure that they have the following line in their ssh configuration

           file on the client machine:

                ForwardAgent no


Revision history

Mar 02, 1998  Updates section - described two cases in which the

              vulnerability is present.


Version: PGP for Personal Privacy 5.0

Charset: noconv





(C) 1999-2000 All rights reserved.