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. Am I crazy? Thanks for your time reading, as always.
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
Alex Wilson wrote:> I'm working on a custom ssh-agent implementation and looking at ways > to detect forwarded agent connections,What about SSH_AGENT_FORWARDING_NOTICE ? It's a "should" in draft-ietf-secsh-agent-02, but if you control your endpoint then you could rely on this, no? //Peter
On 23/5/20 2:21 am, Peter Stuge wrote:> Alex Wilson wrote: >> I'm working on a custom ssh-agent implementation and looking at ways >> to detect forwarded agent connections, > > What about SSH_AGENT_FORWARDING_NOTICE ? > > It's a "should" in draft-ietf-secsh-agent-02, but if you control your > endpoint then you could rely on this, no? >Thanks for the suggestion. I would like it to work with unmodified openssh client binaries already on the system (users just run this agent instead of ssh-agent), so I don't think that would work. If you're curious, the software in question is pivy-agent from https://github.com/arekinath/pivy