It appears there is an opportunity for a denial-of-service attack
against ssh-agent when using ForwardAgent.
This note describes the circumstances, and provides a patch.
Background (not the vulnerability):
If ssh-agent is forwarded to a compromised account, a remote
attacker could use the connection to authenticate as the owner of
the agent. "ssh-add -c" currently defends against this risk by
requiring the owner of the agent to confirm each key access with
$SSH_ASKPASS. This protects against unauthorized remote
authentication, but leaves open other channels of attack.
ssh-agent DoS vulnerability:
The remote attacker controlling the compromised account can still
launch a denial-of-service attack against the ssh-agent session
itself by either (A) locking it ("ssh-add -x") or (B) deleting keys
("ssh-add -[dD]").
This attack effectively disables the agent, and the owner of the
agent is unable to defend against it.
Proposed Workaround:
Add a -r ("require confirmation") flag to ssh-agent. When present,
the agent will use $SSH_ASKPASS to confirm any request to delete
keys or lock the agent. i've attached a patch (against the current
CVS head: ssh-agent.c v1.122 and ssh-agent.1 v1.41) which works for
me.
i welcome any and all feedback. Is this the right way to go about
resolving this problem?
The likelihood of this type of attack on today's 'net is probably low,
and the consequences are of a lower grade than, say, unauthorized
authentication. And of course, ForwardAgent should be kept to a
minimum in general for security.
However, in the circumstances where ForwardAgent is warranted, i'd
like to be able to rely on my local system to alert me to any
tampering with the agent from remote hosts.
Regards,
--dkg
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssh-agent-require-confirmation.diff
Url:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041226/415f2766/attachment.ksh