[ On Tuesday, February 9, 1999 at 01:04:59 (+0100), Peter Svensson wrote: ]
> Subject: Re: transfering files back along an existing connection
>
> The goal is not to prevent the user from doing what he wants but to
> prevent a third party in control of the client computer from doing so.
If there's a third party in control of the client computer, and that
person is not trusted, then you cannot trust the client computer right
from the very beginning.
Even if you trust the person in control of the client computer, and you
authenticate a trusted user and authorize them to open a connection, you
still can not be sure that the person in control of the client computer
hasn't been duped too (which is the nature of the initial exploit
published in Phrack#51 -- fooling even tripwire so that the owner of the
computer cannot tell that it has been riddled by virii and trojans).
You really *must* completely trust the client computer, even if only for
a limited duration of time. Period.
> Your friend in this situation is time. If you are using a separate
> hardware authentication mechanism to log in you will be safe if you log
> out before the third party attempts to hijack the connection.
Maybe. However if the client computer is compromised even before you
try to use it, then even if you try to install your own version of SSH
you'll still not be safe -- the evil could be hiding in the kernel and
while at the same time it is making all your efforts appear to be
successful it is usurping control from you behind your back and doing
nasty deeds in your name.
> The
> connection will be dead and can not be reopened without the hardware key.
The problem is that even one open connection is enough to permit the bad
guy to do nasty things behind your back. You cannot assume that that
what you type and what you see is all that's passed over the connection.
Remember there's an untrusted operating system between your user and the
SSH process that's authenticated him or her and which is protecting the
authorized session from attack on the network.
This is what I meant by suggesting that full auditing of the server end
and hoping you can spot illicit use of the connection.
> If the connection gets hijacked the third party can be thwarted by
> requiring re-authentication each x minutes. Combined with the requirement
> that outgoing connections from the "trusted" network must also be
> authenticated the actions available to the attacker is very limited.
> Unfortunatly it is not a very friendly system to work with either.
Clearly you're not talking about the periodic re-negotiation of the
session key used by SSH but rather the enforced dropping of the
connection (or at least freezing it in a secure manner) and requiring
the user to re-authenticate using the hardware callenge response
system. (Something like this could be less painful if the user used a
tool such as "screen" to maintain his session during re-authentication.)
This is not going to allow you to trust the client computer any more
than you already must to allow the initial connection.
What it will do is give some minor additional assurance that the user at
the keyboard is still the user who initiated the connection -- i.e. the
bad guy hasn't come in and man-handled the keyboard away from your
trusted user. I.e. it'll give you some minor assurance that your *user*
hasn't been hijacked. Of course unless your authentication mechanism is
based on some cryptographically secure and unique biometric that cannot
be used under duress then there's no 100% guarantee that your user can
still be trusted, or can even be trusted at the initial authentication.
The movies are full of examples to how far a villain will go to foil all
of your authentication mechanisms. If you really need this much trust
then SSH and your hardware authentication mechanism are going to be only
one ring of protection amongst many and you'll definitely be sending
your trusted users out into the field with their own laptops that have
hardware encrypted storage, retinal or fingerprint scanners, etc., and
you'll have a team of people on the inside who'll vet each transaction
requested by the man in the field and only re-type it on the trusted
system after several degrees of verification and validation. Real 007
stuff.
> The main case for not using rsa/password authentication as far as I see is
> that the client computer may not be trusted forever. It is very hard to
> safly remove all traces of a file/memory area in any modern os. Chances
> are that somewhere the passphrase/password/key will remain. If the
> reusable information has never been in the computer there is no such risk.
So long as you remove authorization from the server then no matter what
the client remembers it will be useless in the future. That's what I
meant by not having to trust the client forever -- just for the duration
of use. (Of course "PasswordAuthentication no" might be a prerequisite
in this case if you allow reusable passwords inside your trusted
network.)
Using a hardware authentication device releases you from having to be
quite so diligent and timely in your revocation of access, but again the
need to be this careful should be calculated against the risks.
Good hardware authentication devices have real costs as well as their
own administrative overhead and ease-of-use costs.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
