[EMAIL PROTECTED] on 2000.07.21 14:15:40
>> [EMAIL PROTECTED] on 2000.07.18 14:05:01
>> >> How can an SSH server know that the SSH client hasn't been compromised
>and
>> is
>> >> sending a spoofed username?
>> >
>> >By requiring the client to send a password known to the server or to
>encrypt
>> its
>> >connection/keys/whatever it is using the proper private key (in other
>words, a
>> >private key with a corresponding & appropriate public key already known to
>the
>> >server).
>>
>> No, this doesn't guarantee it. For example, if the OpenSSH client sent this
>> info over the server, I can build OpenSSH in such a way that it will always
send
>> the wrong info over. I'll still have proper keys and everything, but the
>> username info will have been spoofed.
>
>But the protocol is standard. If I already have a user's password and private
key,
>why should I bother hacking an OpenSSH client? I could have used any standard
SSH
>client to obtain the same private information.
Depending on the setup, you may not need the user's password (eg the keys were
generated with no password or ssh-agent is running). You would do such a thing
to trick whatever is relying on that information. For example, if CVS has some
code in it (or, more probably some script that runs during a commit), that says:
if [ "$REMOTE_USER" = "nyap" ]
then
echo You are GOD! # Lot's of ego, this one.
fi
then that piece of code can be tricked into thinking that the user really is
nyap. REMOTE_USER cannot be set securely by either SSH or CVS. I chose to send
the info via CVS so I wouldn't have to risk someone thinking, "Hey, SSH sets
REMOTE_USER. I'm sure I can trust its validity."
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
