Detecting forwarded agent connections

[Damien Miller]

On Tue, 19 May 2020, Alex Wilson wrote:

> I know this is pretty left-field, but I'm working on a custom ssh-agent
> implementation and looking at ways to detect forwarded agent connections, with
> the hope to have a "confirm" mode which can apply just to those (or those,
> plus non-whitelisted local processes).
> 
> I realise this has been discussed a bit before, but I have thought up a method
> which seems to be working in my tests so far (which isn't one I've seen
> discussed really?), and wanted to ask if anyone can see an obvious problem
> with it.
> 
> The SSH client makes multiple connections to the agent's UNIX socket when it's
> forwarding -- the first one seems to always be for the client itself (even
> with public key auth disabled), and then subsequent connections are made 1:1
> with remote client connections that are being forwarded.
> 
> My agent implementation already knows how to look up the PID of the connected
> process (via SO_PEERCRED, getpeerucred, etc) and find its executable name and
> basic info (via procfs, kvm_getprocs etc) on the handful of OS that I care
> about, so this is what I'm thinking of doing:
> 
>  1. Track connections per process by pid + process start time (so if the PID
> is re-used, the start time should be different and we'll treat it as new)
>  2. If the calling process' exec binary path ends with "ssh" and this
> connection is NOT the first connection from that process, then prompt for
> confirmation.
>  3. Otherwise, allow it.
> 
> Obviously this won't work if somebody renames the "ssh" binary -- but the
> threat I'm trying to mitigate here is somebody forwarding from a trusted local
> machine to a remote machine which they conditionally trust (e.g. trust it in
> the absence of exploits), and there's not an easy way that I know of to rename
> the local ssh binary from the remote machine.

That would probably work, though I have been toying with trying some
changes to ssh-agent that could make this easier:

1) Make ssh-agent listen on two sockets instead of one, say SSH_AUTH_SOCK
and SSH_AUTH_SOCK_FORWARD.

2) Make ssh _use_ $SSH_AUTH_SOCK, but _forward_ $SSH_AUTH_SOCK_FORWARD
   (this is already possible given the recent change to ForwardAgent)

3) Define some extensions to the agent protocol that allow adding keys
   to ssh-agent for local use only (i.e. not forwarding).

This would let users add keys for local use, keys for remote use w/
confirmation, etc.

What do you think?

-d