Marc Horowitz <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Niels Mvller) writes:
>
> >> Of course, the server can't know that the agent really pays any
> >> attention to that information, but I think that is a minor problem (if
> >> the user wants to be sloppy, its his problem). But perhaps it could
> >> stop abuse of a forwarded agent by a compromized intermediate host;
> >> the server would include enough information in the challenge for the
> >> local agent to recognize that things are not quite right, and then it
> >> refuses signing the challenge.
>
> I don't know how you would come up with a set of rules which would
> automatically work. How does the agent or server tell the difference
> between me logging into a sensitive machine to do real work, and an
> attacker using a compromised agent to log into the same sensitive
> machine to do nefarious things?
Let me think a little. First a scenario:
I run an agent for my private key at a local machine L. I use the
agent to authenticate to two machines, a sensitive server S, and to a
low-security host M.
At first, it may be a really bad idea to forward the agent to M at
all. But we'll assume that I enabled forwarding of the agent to M. We
also assume that I won't ever want to login to S from M (if I did, an
attacker that compromized M could insert commands to my shell on S and
do all sorts of evil things).
Next, let's assume that an attacker gets access to my forwarded agent
on M, and attempts to login to S in my name. He connects to S from
some other host C (its possible but not necessary that C = M. It's
even possible that C = L, which is the most difficult case, I think).
Now S creates a challenge for the attacker. Let the challenge be a
message <random nonce, host (=S), peer (=C), "login-service",
"nisse">. (The C field is not very reliable, as it's based on the peer
ip address). The correct response to the challenge is a signature on
this message, using my private key.
Now, let's look at how I could configure the agent and
agent-forwarding software. It could look at all the fields in the
message before creating a signature. Using the peer field, we can
refuse to sign login-challenges to S unless the peer is L. That was
what I was thinking about in the previous message. This gains a little
security, but fails if the attacker can login to L, or do serious
ip-spoofing.
To get something better, we would need to attach some more information
to the challenge on its way to the agent. My local ssh that manages
the connection L->M could transform it into <challenge received via M,
<random nonce, S, C, "login service">> before passing it on. I think
this can be done in such a way that this side information can be
trusted (at least the information about the first hop from L), assuming
only that the local protection of the agent on L is not by-passed.
So the agent could use this information to deny signing any challenges
that are received via M, and that request login access to S.
Does this make sense? It seems likely that the existing ssh-agent
forwarding don't do this (from the short description of ssh-agent
forwarding in the ssh connection spec, it seems that it provides a raw
connection to the agent with no obvious place to insert the side
information about the path). So the interesting question is if it is a
viable approach, if we were to design a new ssh-auth-forwarding
mechanism from scratch.
And if anybody knows about the inner workings of ssh-agent (preferably
version 2), or even better, has access to the spec. I'd really like to
know what kind of information is included in the challenges.
/Niels
