openssh bugs - Aug 2017 - [Bug 2766] New: support "--" to disambiguate option and non-option arguments

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

            Bug ID: 2766
           Summary: support "--" to disambiguate option and non-option
                    arguments
           Product: Portable OpenSSH
           Version: 7.5p1
          Hardware: Other
               URL: https://bugs.debian.org/873201
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cjwatson at debian.org

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.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Blocks|                            |2698
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I fixed this a couple of weeks ago.

commit 643c2ad82910691b2240551ea8b14472f60b5078
Author: djm at openbsd.org <djm at 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


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2698
[Bug 2698] Tracking bug for OpenSSH 7.6 release
-- 
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=2766

--- Comment #2 from Colin Watson <cjwatson at debian.org> ---
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.

-- 
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=2766

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after release of OpenSSH 7.7.

-- 
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.