[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    BoS: SECURITY PROBLEM IN SSH (fwd)
From:       halflife <halflife () saturn ! net>
Date:       1996-01-18 19:59:52
[Download RAW message or body]



---------- Forwarded message ----------
Date: Thu, 18 Jan 1996 18:08:08 +0200
From: Tatu Ylonen <ylo@cs.hut.fi>
To: ssh-announce@clinet.fi, ssh@clinet.fi
Subject: SECURITY PROBLEM IN SSH

There is a security problem in ssh (client) that permits any user on
the local machine to get access to the private host key (which in turn
can make the machine vulnerable to man-in-the-middle attacks and
compromises RhostsRSA authentication from that host, when combined
with IP-spoofing).

In other words, this attack can bring your security down almost to the
level provided by the rsh/rlogin programs (passwords are still not
transmitted in the clear and you still cannot be ip-spoof blindly).

It does not make you worse off than existing rsh/rlogin based
solutions, but I consider the problem quite serious.  It can make you
vulnerable to active ip-spoofing/routing-spoofing/dns-spoofing attacks
after a malicious local user has stolen the private host key.

The attack works by sending a signal to the client right after it
switches back to user privileges, causing it to core dump.  The
private host key can then be extracted from the core dump.

This mail is just to confirm the existence of the problem.  The
problem affects all unix versions of ssh.  I'll try produce a fix
shortly.

Below is the original message from Barry Jaspan, and followups by
Thomas Koenig and David Mazieres.

    Tatu


From: Barry Jaspan <bjaspan@bbnplanet.com>
To: ssh@cs.hut.fi, ssh-bugs@cs.hut.fi
Subject: Security bug in ssh.c (1.2.0)
Date: Wed, 17 Jan 96 16:46:28 EST

Responding to a challange from Wayne Schroeder <schroede@sdsc.edu>, I
just found a bug in the RSA Rhosts code in ssh.c that allows any user
that can run the ssh client to obtain the private key of the host it
is running on.  Once an attacker has that key, of course, he can break
the security of any host that trusts the attacked host.

The bug is that ssh.c does not erase the host's private key from
memory before setuid()ing back to the user.  Therefore, it is possible
for the user to access the memory containing the private key before it
is erased.

The attack is simple.  The user runs ssh, watches (via stat()) for the
access time on /etc/ssh_host_key to change, and as soon as it does
sends a SIGSEGV to the process.  It is then a simple matter of running
a debugger on the core image to extract the private key.  I performed
the attack with a 15 line perl script that I wrote in about 20
minutes.

A user cannot send a signal to a root process.  Therefore, the bug can
be eliminated by erasing the key from memory before relinquishing root
privileges.  Of course, this means a lot more code has to be run as
root, and all that code will have to be verified to be setuid-safe.

Lessons to be learned:

o Host-based trust is a BAD IDEA.  Securing it with RSA does not
change the fact that compromise of a single host compromises all the
hosts that trust it.  No one should use the RSA Rhosts mode of SSH if
they care about security.  SSH should not even include that
functionality.

o SSH is too new to be trusted for real security applications.  It
needs to be tested and evaluated by security experts over a long
period of time.  I found and exploited a critical bug in only about 20
minutes.  How many others remain to be discovered?

Barry


From: Thomas.Koenig@ciw.uni-karlsruhe.de (Thomas König)
To: bjaspan@bbnplanet.com (Barry Jaspan)
Cc: ssh@clinet.fi
Subject: Re: Security bug in ssh.c (1.2.0)
Date: Thu, 18 Jan 1996 01:33:20 +0100 (MET)

>Responding to a challange from Wayne Schroeder <schroede@sdsc.edu>, I
>just found a bug in the RSA Rhosts code in ssh.c that allows any user
>that can run the ssh client to obtain the private key of the host it
>is running on.  Once an attacker has that key, of course, he can break
>the security of any host that trusts the attacked host.

While I agree that this is a bug that needs fixing, I still don't
think the consequences are as grave as you describe.

RSARhosts authentication still needs root access on that particular
box, or (alternatively) IP spoofing.

The first - well, if somebody has cracked root on your host, security
is lost in any case.  I don't think there are many UNIX versions
around on which a determined cracker with the right information cannot
gain root access by some other means (and then could read the private
host key directly).

It's important to remember that ssh provides security at the network
level, NOT at the host level.

>o Host-based trust is a BAD IDEA.  Securing it with RSA does not
>change the fact that compromise of a single host compromises all the
>hosts that trust it.  No one should use the RSA Rhosts mode of SSH if
>they care about security.  SSH should not even include that
>functionality.

That's why it can be switched off, you know :-)

Often, there's a tradeoff between usability and security.  If you think
that a feature can cause you harm, you can always switch it off.  I
don't think it is ssh's job to enforce policy; rather, it is ssh's
job to offer the options on which a reasonable policy can be based.

"If they care about security" is too broad a generalization to be really
useful.  If you care about security, don't let people get near your
computer, and most certainly don't hook it up to a network.

>o SSH is too new to be trusted for real security applications.  It
>needs to be tested and evaluated by security experts over a long
>period of time.

Depends on the level of security you need.  If you use a current
UNIX system... well, using ssh can hardly degrade security, can
it? :-)
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.


From: David Mazieres <dm@amsterdam.lcs.mit.edu>
To: bjaspan@bbnplanet.com
Cc: ssh@cs.hut.fi, ssh-bugs@cs.hut.fi
Subject: Re: Security bug in ssh.c (1.2.0)
Date: Wed, 17 Jan 1996 22:29:42 -0500

> Date: Wed, 17 Jan 96 16:46:28 EST
> From: Barry Jaspan <bjaspan@bbnplanet.com>
> 
> A user cannot send a signal to a root process.

That's not true, by the way.  As long as the setuid-root process's
real user-id is yours you can send the process a signal.  For instance
in OpenBSD (which is close to NetBSD and many other operating
systems), in /sys/kern/kern_sig.c:

/*
 * Can process p, with pcred pc, send the signal signum to process q?
 */
#define CANSIGNAL(p, pc, q, signum) \
        ((pc)->pc_ucred->cr_uid == 0 || \
            (pc)->p_ruid == (q)->p_cred->p_ruid || \
            (pc)->pc_ucred->cr_uid == (q)->p_cred->p_ruid || /* <-- HERE */\
            (pc)->p_ruid == (q)->p_ucred->cr_uid || \
            (pc)->pc_ucred->cr_uid == (q)->p_ucred->cr_uid || \
            ((signum) == SIGCONT && (q)->p_session == (p)->p_session))

Of course, being able to signal a setuid process does not mean you can
get it to dump core.

> Lessons to be learned:
>
> o Host-based trust is a BAD IDEA.  Securing it with RSA does not
> change the fact that compromise of a single host compromises all the
> hosts that trust it.  No one should use the RSA Rhosts mode of SSH if
> they care about security.  SSH should not even include that
> functionality.

Again, you are incorrect.  A correctable implementation mistake
teaches us nothing about the inherent security of Host-based trust.

The theoretical implications of this particular bug notwithstanding,
host based security is quite plausible in many network configurations.
Anyone who compromises my workstation, for instance, can ptrace my
ssh-agent and tamper with such files as ssh, ssh-add, pgp, md5,
tripwire, cfsd, libc.so, and so forth.  An ssh_host_key readable only
by root does not further degrade the security of my environment.

On the other hand, in an open workstation cluster where everyone has
physical access to the machines, host-based security is probably not
acceptable.  Then again, that sort of machine would probably not even
have an ssh_host_key, let alone be in someone's .shost or
.ssh/known_hosts file.

> o SSH is too new to be trusted for real security applications.  It
> needs to be tested and evaluated by security experts over a long
> period of time.  I found and exploited a critical bug in only about 20
> minutes.  How many others remain to be discovered?

Probably many fewer than in any other freely available network login
package for Unix--Unless you know about some software that I don't.
There is a tremendous lack of secure software for Unix platforms.
Ssh, through its portability and ease of use, is a monumental step in
the right direction.

Even with the security hole you just found, ssh is still MORE
difficult to exploit than kerberos.  Ssh may still be new and contain
bugs.  Nonetheless, it is likely far better than whatever else you are
currently using.

David

[prev in list] [next in list] [prev in thread] [next in thread]