openssh bugs - Oct 2014 - [Bug 2283] New: option to execute command without shell

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

            Bug ID: 2283
           Summary: option to execute command without shell
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: pabs3 at bonedaddy.net

ssh has always been confusing when it comes to quoting because it runs
commands on the remote side with the system shell. It would be nice if
there were a mode where commands could be run using fork()+exec() or
similar, without invoking the shell. This would help avoid quoting
confusion, shell metacharacter attacks and things like shellshock.

This appears to require a protocol extension to work since RFC 4254
specifies just a string to be passed with exec:

https://tools.ietf.org/html/rfc4254#section-6.5

There could be:

A client-side option to turn it on.

A server-side option (sshd_config, authorized_keys) to allow it.

A server-side option (sshd_config, authorized_keys) to disallow
in-shell commands and interactive shells.

A way to pass the original command requested by the user to the forced
command that uses NUL characters to separate arguments instead of
spaces. Maybe ORIGINAL_SSH_COMMAND_N environment variables would be the
way to do it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
What's your use case for this?

In the past I've done this kind of thing to avoid one layer of shell
quoting, but it only works for cases where you don't want the remote
end to read stdin:

$ ssh localhost /bin/sh <<EOD
> echo '"'
> EOD
"

vs

$ ssh localhost /bin/sh echo '"'
bash: -c: line 0: unexpected EOF while looking for matching `"'
bash: -c: line 1: syntax error: unexpected end of file

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #2 from Paul Wise <pabs3 at bonedaddy.net> ---
As I said in the first post, this would help avoid quoting confusion (a
never-ending problem for me), shell metacharacter attacks and things
like shellshock.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
That's not a use case.  I'm looking for an example of something that
could be done with what you're asking for but can't be done other ways.

What you're asking for involves a non-standard extension and
maintenance pretty much indefinitely so I'm trying to figure out if
it's worth the effort and why.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #4 from Paul Wise <pabs3 at bonedaddy.net> ---
I don't have any more specific use-cases, sorry.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Mattia Rizzolo <mattia at mapreri.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mattia at mapreri.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Salvador Fandi?o <sfandino at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sfandino at yahoo.com

--- Comment #5 from Salvador Fandi?o <sfandino at yahoo.com> ---
3 use cases:

- quoting properly requires knowing the user remote shell or
auto-detecting it. This complicates creating scripts that connect to a
bunch of machines and do something.

- security issues: passing some data from an untrusted source (i.e. a
web POST) to a remote machine requires quoting the data. But creating a
generic quoter can be daunting and edge cases or bugs on the shell may
be exploited. This is a similar case to sql injection problem, where
using placeholders is far securer than quoting.

- lazy people: as quoting by hand requires work it is pretty common for
people writing scripts to just ignore the issue completely resulting in
crappy scripts. If it were as easy as adding a flag to the command
line, well maybe more people would use it.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Colin Watson <cjwatson at debian.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjwatson at debian.org

--- Comment #6 from Colin Watson <cjwatson at debian.org> ---
(In reply to Darren Tucker from comment #3)
> That's not a use case.  I'm looking for an example of something
that
> could be done with what you're asking for but can't be done other
> ways.
The thing that is straight-up impossible with OpenSSH's current
facilities is to reliably invoke a command with non-trivial arguments
on the server when you don't know the user's login shell.  If you know
the shell, then you can always reverse its quoting algorithm (well, as
long as the shell is at least moderately sensible), but if you're
building a general program that uses ssh as a building block then you
can't rely on this, even if you can rely on having OpenSSH at both
ends.

This is an important omission.  Still, I'd argue it's the wrong bar to
set.  Quoting is notoriously hard to get right, especially when OpenSSH
barely documents its current behaviour at all.  sshd(8) says that "all
commands are run under the user's login shell", but that's as far
as it
goes; ssh(1) makes no mention of the command execution behaviour
whatsoever, even neglecting to mention the "join arguments with
spaces"
thing which is specifically something that the ssh client does.

But even if it were properly documented (an unusual omission for
OpenSSH, really), at the risk of trying to teaching you how to suck
eggs, part of building secure systems is having clear APIs that are
hard to get wrong, and OpenSSH's current command execution API is
neither clear nor straightforward.  Essentially every modern
programming language has realised for some time that it needs to
provide a clear way to pass separate arguments in its local command
execution API; OpenSSH is a long way behind here.  I understand that
it's mainly a protocol failure and not OpenSSH's fault as such, aside
from the documentation problems, but OpenSSH doesn't seem like a
terrible place to start either.

I wonder if there's some hope of coming up with something that could be
standards-track, so that OpenSSH isn't stuck with something
non-standard forever?  Perhaps something like this as an extension to
the connection protocol:

  byte      SSH_MSG_CHANNEL_REQUEST
  uint32    recipient channel
  string    "exec-list"
  boolean   want reply
  string[]  arguments

... together with a behaviour specification, probably indicating that
the first argument should be looked up in the system's search path as
the command and that the remaining arguments should be passed to it in
such a way that the command sees them as separate arguments.  (Unix
servers could use execvp; Windows servers would have to do their own
quoting such that a call to CommandLineToArgvW in the subprocess will
do the right thing, or something along those lines.)

As Paul says, use of this would have to be governed by a client-side
option, and various other bits and pieces: using it unconditionally if
the server advertised support for it would certainly break
compatibility in cases where people have relied on the current quoting
semantics.  It would be a while before we could rely on this even in
OpenSSH-only environments.  But being able to have reliable quoting in
five years would still be a lot better than never having it.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #7 from Colin Watson <cjwatson at debian.org> ---
(In reply to Colin Watson from comment #6)
> The thing that is straight-up impossible with OpenSSH's current
> facilities is to reliably invoke a command with non-trivial
> arguments on the server when you don't know the user's login shell.
Quick amendment before somebody else points it out: as Darren noted in
comment #1, you can do it if the remote command doesn't need to read
stdin.  But that often isn't enough.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #8 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Colin Watson from comment #6)
> (Unix servers could use execvp; Windows servers would
> have to do their own quoting such that a call to CommandLineToArgvW
> in the subprocess will do the right thing, or something along those
> lines.)
One thing you'd need to be careful of is that the user's shell is
sometimes used as an access control method (rbash, nologin or even just
/bin/true) so bypassing it and going straight to excevp could prove
quite the surprise.

Also:
> Essentially every modern programming language
Despite the featuritis in Match, OpenSSH is not a programming language
:-)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Florian Weimer <fweimer at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Grisha Levit <grishalevit at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grishalevit at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Mikel Ward <mikel at mikelward.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikel at mikelward.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #9 from Paul Wise <pabs3 at bonedaddy.net> ---
Some discussion from the internet about this issue:

https://www.chiark.greenend.org.uk/~cjwatson/blog/ssh-quoting.html
https://news.ycombinator.com/item?id=27483077
https://lobste.rs/s/8tki7j/ssh_quoting

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #10 from Paul Wise <pabs3 at bonedaddy.net> ---
Some discussion from the internet about this issue:

https://www.chiark.greenend.org.uk/~cjwatson/blog/ssh-quoting.html
https://news.ycombinator.com/item?id=27483077
https://lobste.rs/s/8tki7j/ssh_quoting

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

github at kalvdans.no-ip.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |github at kalvdans.no-ip.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

--- Comment #11 from Paul Wise <pabs3 at bonedaddy.net> ---
Another thread where this was discussed:

https://news.ycombinator.com/item?id=43457816

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

kpcyrd <kpcyrd at archlinux.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kpcyrd at archlinux.org

--- Comment #12 from kpcyrd <kpcyrd at archlinux.org> ---
There's a writeup on the reproducible-builds mailing list from
September 2023 that (ab-)uses this ssh quirk as an example
underhanded-eval gadget (the rest of that writeup is not relevant to
this issue):

https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/003075.html

There's a missed opportunity in that writeup because even when passing
the output of `git describe` through it's own argument it's going to
get remotely eval'd:

ssh 'some-server' './foo.bin' '--'
'$(id>pwned)'

While it's true that ssh is not a programming language, with
command-line interfaces there's usually an assumption that you can
trivially pass opaque strings from one program to another, this is not
the case with ssh however. A user would usually expect this to be
executed as:

./foo.bin '--' '$(id>pwned)'

on the remote server, with all bytes passed as-is to argv and no
shell-eval taking place. In shell scripting, this would be considered
safe-and-sound to pass opaque data:

./foo.bin -- "$@"

However, this is not and might get you hacked:

ssh 'some-server' -- ./foo.bin -- "$@"
> I'm looking for an example of something that could be done with what
you're asking for but can't be done other ways.
If I made an eval-based json parser I could argue it's the caller's
fault and safe use of my function "can be done" if you try hard
enough.

I understand the compatibility concerns, but please reconsider.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.