command [argument ...] in ssh(1): a footgun

[Peter Stuge]

raf wrote:
> > > Not knowing the details of each user's login shell is
> > > precisely the reason that ssh couldn't ever do the
> > > quoting itself.
> > 
> > The footgun is unrelated to shells.
> > 
> > The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254)
> > channels which are used to run a single remote command contains
> > exactly one string for the command.
> > 
> > sshd (see bottom of do_child() in session.c) runs that command string as:
> > 
> > remote_users_shell -c command
> 
> I'm aware of that. That's why I said what I said.
> Sorry, but I don't understand what point you are making.

My point wasn't directed at you specifically, rather at the thread in general.


Jochen Bern wrote:
> Let's summarize the general situation, though:
> -- We cannot reduce the local shell's influence re: quoting to zero

This happens before the ssh client process starts.


> -- We cannot reduce the remote shell's influence to zero as long as
>     sshd(8) uses that to execute the command.

As I pointed out sshd always uses the shell. (Bottom of session.c:do_child())


> -- If we avoid that and execv() the command directly,

The protocol transfers a single command string to the server. The
server has no array to pass to execv().


> I *could* see a "switch to remote direct execv()" *option* on the (far) 
> horizon, but not a change of the default behavior.

I tried to make clear that the protocol does not allow such an option.


> use some sort of encoding on the command transmitted from ssh to sshd

The protocol message is binary transparent; it's certainly possible
to serialize a data structure into the command string and use a shell
on the server that deserializes its -c argument. Seems convoluted though.


//Peter