openssh bugs - Mar 2009 - [Bug 1572] New: accept SOCKS requests over the mux socket in master mode

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

           Summary: accept SOCKS requests over the mux socket in master
                    mode
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: sfandino at yahoo.com


Created an attachment (id=1613)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1613)
patch for OpenSSH current

The attached patch extends the mux listener to accept SOCKS4/5 requests
in addition to the native mux commands.

The rationale behind is that creating tunnels attached to TCP ports is
a security hazard in multi-user machines where there is no way to
control who connects through the tunnels. On the other hand, The mux
UNIX domain socket binds to the file system and regular permissions can
be used for access control.

I have also created a small Perl script "snc", similar to netcat, that
uses this new feature. In the end, if this patch gets accepted, my idea
is to extend my Perl module Net::OpenSSH to use it.

Under the hood, the code I have added just looks at the first byte
coming from the mux connection. When it is a mux command, it
corresponds to the first byte for the packet length encoded as a 32bits
integer in network order and so, it is 0 (packet length is limited to
256KB). When it is a SOCKS connection the first byte is 4 or 5 so we
can easyly distinguish both protocols.

I know it is somewhat hacky, but the alternatives I see are:

1) to use a dedicated socket for the SOCKS proxy

2) to extend the mux "protocol" with new commands offering equivalent
functionality.

I don't like (1) because, IMO, it would unnecessarily complicate ssh
usage. I don't like (2) because adapting a SOCKS client to use a UNIX
socket instead of a TCP one, should be much easier than implementing a
new protocol.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #1 from Salvador Fandi?o <sfandino at yahoo.com>  2009-03-11
20:13:55 ---
Created an attachment (id=1614)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1614)
prove of concept, perl script

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #2 from Salvador Fandi?o <sfandino at yahoo.com>  2009-03-11
20:16:41 ---
Created an attachment (id=1615)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1615)
patch for dsocks-1.6

patch for dsocks-1.6 (http://www.monkey.org/~dugsong/dsocks/) that adds
support for connecting to the SOCKS server through an UNIX domain
socket.

For instance, with these patches applied to dsocks and ssh, I can run:

$ ssh -M -S /tmp/mux 172.20.3.12 -N -f
$ LD_PRELOAD=/root/my-dsocks-1.6/libdsocks.so.1.0 \
     DSOCKS_PROXY=/tmp/mux \
     DSOCKS_NAMESERVER=172.20.4.17 \
     lynx www.openbsd.org

And browse the web without opening a local listening port on my
computer for the SOCKS proxy.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #3 from Salvador Fandi?o <sfandino at yahoo.com>  2009-03-13
02:27:48 ---
Discussion about this feature taking place in
openssh-unix-dev at mindrot.org

On Mar 11, 2009, at 1:21 PM, Jim Knoble wrote:
> > Circa 2009-03-11 10:27 dixit Ben Lindstrom:
> >
> > : I'm concerned that people will become confused since -M -S combo
has
> > : been resevered for multiple ssh terminal sessions over a single
> > : tunnel.  I'd rather see it more clear like:
> > :
> > : ssh -D -M -S /tmp/mux 172.20.3.12 -N -f   if you want multiple  
> > tunnels
> > : + SOCK support
> > : ssh -D -S /tmp/mux  .. if you just want SOCKS support instead of a  
> > PORT
> > :
> > : Which means an error needs to be throw on
> > :
> > : ssh -Dxxx  -S xxxx
> >
> > The above means that you can't separate permissions for the mux
socket
> > and the SOCKS socket.
> >
> > Better to create a dedicated SOCKS socket, no?
> >
> >  ssh -D /tmp/ssh-socks-socket ...
> >
> > That is, '-D' may accept either an IP address or a filesystem
path.
> > Reserve '-S' for use with multiplexing sockets.  This way, one
can:
> >
> >  ssh -D /tmp/ssh-socks-socket -M -S /tmp/ssh-mux-socket ...
> >
> > and allow more than one user to use the SOCKS connection while keeping
> > the mux socket more private.
> >
> > This also makes the '-D' syntax consistent and sensible.
> >
That works for me.   I just found the mutation and corruption of -M -S  
to be a bit dodgy when we already have a -D that is clearly tagged as  
being a socks4/5 server functionality flag.

- Ben

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #4 from Salvador Fandi?o <sfandino at yahoo.com>  2009-03-13
03:12:15 ---
Created an attachment (id=1616)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1616)
use UNIX domain sockets instead of INET for tunnel listeners, proof of
concept

Following the discussion on openssh-unix-dev at mindrot.org, the new patch
attached uses a different UNIX socket instead of reusing the
multiplexer one.

Now, it is possible to run...

  $ ssh -D/tmp/foo my.host.com -N

and also...

  $ ssh -L/tmp/bar:remote.host.com:22 -N


For instance, now, this works:

  $ ssh -L/tmp/listener:mandeo:22 10.0.2.2 -N -f
  $ ssh -o ProxyCommand="socat STDIO UNIX-CONNECT:/tmp/listener"
mandeo


A "port" is parsed as a UNIX path when it contains some slash.

Unfortunately, slashes already had a meaning on tunnel specifications
as they were used with IPv6 addresses. I had to remove that feature in
order to implement mine... I know this is a bad idea, but this is just
a prove of concept so, forgive me!

I can see two solutions for that:

1) use a different set of flags:

 $ ssh -E/tmp/foo ...                 # instead of -D
 $ ssh -K/tmp/bar:my.host.com:22 ...  # instead of -L

it still doesn't play well with IPv6 addresses as parsing (and writing)
things like...

 $ ssh -K/tmp/bar:::1/22

correctly can be quite tricky.


2) use some kind of special quoting

 $ ssh -D'</tmp/foo>' ...

I like it, but has the inconvenient of <> needing quoting for the
shell. {} and () are also processed by the shell.

{} is probably the less problematic as it will not be modified by the
shell unless some comma is found inside, something unusual for file
names.


Personally, I would go for -D{/tmp/foo}

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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


Jim Knoble <jmknoble at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmknoble at pobox.com




--- Comment #5 from Jim Knoble <jmknoble at pobox.com>  2009-03-13
09:34:35 ---
Circa 2009-03-12 11:22 dixit Salvador Fandino:

: > From: Jim Knoble <jmknoble at pobox.com>
: > Sent: Wednesday, March 11, 2009 7:21:54 PM
: > 
: >   ssh -D /tmp/ssh-socks-socket ...
: 
: I have attached a new patch to the request at...
: 
:   https://bugzilla.mindrot.org/show_bug.cgi?id=1572
: 
: doing just that.
: 
: There is a problem with it and is that slashes already have an
special
: meaning on tunnel specifications , they are used with IPv6 addresses.

The syntax you're speaking of is (from ssh(1)):

    IPv6 addresses can be specified with an alternative syntax:
    [bind_address/]port/host/hostport
    or by enclosing the address in square brackets.

There's a key difference between that syntax and the Unix-domain socket
path:  The leading slash of an absolute path.  That is:

    # Listen on IPv6 address ::1 on port 2222, forward across the
    # ssh link to address ::1, port 22

    ssh -L ::1/2222/::1/22

    # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and
    # forward across the ssh link to address 127.0.0.1, port 22

    ssh -L /tmp/my-ssh-forward-sock:127.0.0.1:22

    # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and
    # forward across the ssh link to address ::1, port 22
    # TODO: Does this work: -L [::1]:2222:[::1]:22

    ssh -L /tmp/my-ssh-forward-sock:[::1]:22

    # Syntax error (too many ':')

    ssh -L /::1/2222/::1/22

In words: If the first character of the argument to -L is '/', it's
a
filesystem path, and ':' is required to be the sub-argument separator.
Remote IPv6 addresses must be enclosed in square brackets.  Otherwise,
the syntax is the same as before.

Are there plans to implement domain sockets for '-R'?  If so:

    # Listen on the remote address ::1 on port 2222, forward back
across
    # the ssh link to address ::1, port 22

    ssh -R ::1/2222/::1/22

    # Listen on the remote address 127.0.0.1 on port 2222, forward back
    # across the ssh link to the socket at /tmp/my-service-sock on the
    # host ssh is running on

    ssh -R 127.0.0.1:2222:/tmp/my-service-sock

    # Listen on the remote address ::1 on port 2222, forward back
across
    # the ssh link to the socket at /tmp/my-service-sock on the host
ssh
    # is running on

    ssh -R [::1]:2222:/tmp/my-service-sock

    # Syntax error (probably produces either "tmp: host not found" or
    # "my-service-sock: unknown port")

    ssh -R ::1/2222/tmp/my-service-sock

In words, if '/' is used as the subargument separator, then Unix domain
sockets cannot be specified.  If ':' is used, remote IPv6 addresses
must be specified in square brackets, and if the first character of the
"local" host specification is '/', then it's a Unix domain
socket.

If you want Unix domain sockets to be used with -L or -R on the remote
end as well, that works the same as above, only with -L and -R
reversed.
To forward between Unix domain sockets on both ends, you get:

    ssh -L /tmp/ssh-forward-sock:/tmp/my-service-sock

(I.e., only 2 subarguments, separated by ':').  Same for -R. 
Obviously,
sshd would have to be patched to support that.

Anything i missed, for -L or -R?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #6 from Jim Knoble <jmknoble at pobox.com>  2009-03-13
16:41:56 ---
Date: Thu, 12 Mar 2009 17:51:27 -0700
From: William Ahern <william[snip]25thandClement[snip]com>
To: [snip] openssh-unix-dev at mindrot.org
Subject: Re: [PATCH] accept SOCKS request over the mux socket
Message-ID: <20090313005127.GA12637 at wilbur.25thandClement.com>

On Thu, Mar 12, 2009 at 05:31:35PM -0500, Jim Knoble wrote:
<snip> 
> Are there plans to implement domain sockets for '-R'?  If so:
> 
>     # Listen on the remote address ::1 on port 2222, forward back
>     # across the ssh link to address ::1, port 22
> 
>     ssh -R ::1/2222/::1/22
> 
>     # Listen on the remote address 127.0.0.1 on port 2222, forward
>     # back across the ssh link to the socket at /tmp/my-service-sock
>     # on the host ssh is running on
> 
>     ssh -R 127.0.0.1:2222:/tmp/my-service-sock
First of all, you have to modify the wire protocol to request remote
domain socket forwarding. When I did it, it was relatively simple.
But...

Second of all, there are security issues with domain sockets. One of
the
pains of domain sockets in general is you can't simply set
SO_REUSEADDR.
To make them practical, you have to (at least provide the option to)
unlink() the path. Otherwise broken connections and other regular
happenstances will make live miserable to make use of the capability.
And for all but the most convoluted solutions, there are still races
and
other uncertainties.

<snip>
> In words, if '/' is used as the subargument separator, then Unix
> domain sockets cannot be specified.  If ':' is used, remote IPv6
> addresses must be specified in square brackets, and if the first
> character of the "local" host specification is '/', then
it's a Unix
> domain socket.
> 
> If you want Unix domain sockets to be used with -L or -R on the remote
> end as well, that works the same as above, only with -L and -R
> reversed.  To forward between Unix domain sockets on both ends, you
> get:
> 
>     ssh -L /tmp/ssh-forward-sock:/tmp/my-service-sock
> 
> (I.e., only 2 subarguments, separated by ':').  Same for -R.
> Obviously, sshd would have to be patched to support that.
> 
The way I implemented it was I re-wrote the the -L and -R parser to be
more generic, using a small state machine rather than ad-hoc string
parsing. The most straight-forward syntax would be to require domain
paths to be between braces; then there's no conflict (unless your path
contains brances, but you can escape those), and you don't even
necessarily need to require absolute paths, because the brace syntax
can
bootstrap you into a new syntax domain.  For instance:

    -R[/tmp/remote-foo]:[/tmp/local-bar]

Or perhaps:

    -R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar]

(I'm unfamiliar with the sftp spec, but I bet there's a useful syntax
there, too.)

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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





--- Comment #7 from Jim Knoble <jmknoble at pobox.com>  2009-03-13
17:01:31 ---
On 2009-03-12 19:51, William Ahern wrote:

: The way I implemented it was I re-wrote the the -L and -R parser to
be
: more generic, using a small state machine rather than ad-hoc string
: parsing. The most straight-forward syntax would be to require domain
: paths to be between braces; then there's no conflict (unless your
path
: contains brances, but you can escape those), and you don't even
: necessarily need to require absolute paths, because the brace syntax
: can bootstrap you into a new syntax domain.  For instance:
: 
:       -R[/tmp/remote-foo]:[/tmp/local-bar]

This is interesting.  Salvo had proposed using curly braces '{' and
'}'
for this, which may be necessary, as IPv6 addresses are curently
allowed
to be inside square brackets '[' and ']'.  Haven't looked at
the code,
though.

: Or perhaps:
: 
:      
-R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar]

Aha.  Thanks, William, for pointing out what I missed: the possibility
of relative paths for the remote end.

This is very interesting, and obviously URI-style specifiers are
relatively commonplace these days.  I would get rid of the '//' after
the ':', as it is supposed to denote a host, but with Unix domain
sockets, the host is implied to be one of the hosts at either end of
the
SSH connection.  Thus:

    -R[unix:some/relative/path/remote-foo]:[unix:/tmp/local-bar]

should be sufficient.  I don't mind the extra typing associated with
the
square brackets and the URI-style specifier, as i suspect this usage
wouldn't be terribly commonplace anyway.  It also allows square
brackets
to be used without conflicting with the optional square brackets around
IPv6 addresses.  I'm in favor of this.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #8 from Damien Miller <djm at mindrot.org>  ---
Is this patch necessary now that we support stdio forwarding over the
mux socket now? A client could speak the SOCKS protocol on one side and
the mux protocol on the other...

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- 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.