I'm forwarding verbatim a bug report from Thorsten Glaser (also at the attached URL). The intemperate language is not mine, but I decided against editing it. ssh of course doesn't document "--" as part of its interface, so IMO all the uses of "should" here are with reference to an idealised interface rather than the documentation. Nevertheless, it does seem that it would be extremely useful to have a reliable way to disambiguate between options to ssh itself and options that should be passed to the remote command. --- Subject: command line parsing with -- between option and non-option arguments completely broken Hi, in the process of me fixing CVE-2017-12836 a user noticed a problem with OpenSSH’s command line parsing. I’ve verified these on OpenSSH 5.3 (MirBSD) and 7.5p1 (Debian). So, to begin with, this command _should_ spawn xeyes: $ ssh -oProxyCommand=xeyes vuxu.org This command _could_ spawn xeyes on glibc systems, but probably shouldn’t on POSIX or BSD systems: $ ssh vuxu.org -oProxyCommand=xeyes This command properly does not spawn xeyes but tries to resolve “-oProxyCommand=xeyes” as hostname, correctly failing: $ ssh -- -oProxyCommand=xeyes This command *must not* spawn xeyes, but does: $ ssh -- vuxu.org -oProxyCommand=xeyes This instead must execute “-oProxyCommand=xeyes” as command on the remote side. Interestingly enough, this command works the same and also mustn’t but also doesn’t: $ ssh vuxu.org -- -oProxyCommand=xeyes Now it gets completely weird, this doesn’t spawn xeyes either: $ ssh -- vuxu.org -- -oProxyCommand=xeyes This “should” execute “--” as command with “-oProxyCommand=xeyes” as its first option on the remote site, but judging from the error | mksh: ProxyCommand=xeyes: unknown option it instead passes “-oProxyCommand=xeyes” as option to a shell on the remote side. I don’t do the security theatre, but this could perhaps be considered missing command escaping on the remote side (passing what would be a command as an option to the remote shell) in addition to completely fucked up option parsing on the local side. This was first reported by nickserv-auth’d user jn__ on #musl on Freenode IRC, and leah2 forwarded it to me as current de-facto maintainer of GNU CVS because I considered adding “--” between option and nōn-option arguments sufficient for fixing the afore‐ mentioned CVE, judging this effective enough with normal command line parsing rules (as in getopt(3) on OpenBSD) and given the .Sx SYNOPSIS in the ssh manpage.
I fixed this a couple of weeks ago. commit 643c2ad82910691b2240551ea8b14472f60b5078 Author: djm@openbsd.org <djm@openbsd.org> Date: Sat Aug 12 06:46:01 2017 +0000 upstream commit make "--" before the hostname terminate command-line option processing completely; previous behaviour would not prevent further options appearing after the hostname (ssh has a supported options after the hostname for >20 years, so that's too late to change). ok deraadt@ Upstream-ID: ef5ee50571b98ad94dcdf8282204e877ec88ad89
Ah, of course, thanks! Sorry for not noticing that. It would be nice if this were documented in ssh(1). Programs that call other programs that execute subsidiary commands often need to know in pedantic detail exactly what the quoting (etc.) requirements of those other programs are.
Close all resolved bugs after release of OpenSSH 7.7.