Mailing List Archive

[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-24 14:27 -------
Created an attachment (id=782)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=782&action=view)
forward-bind.sh: regression test for binding port forwards to addresses

Current limitations of test:
- no testing of IPv6
- no testing of backwards compat with <=3.9



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-24 15:13 -------
(In reply to comment #18)
> - Resolve the 127.0.0.1 issue

I just reread the spec (draft-secsh-connect23) and it's not clear how to do that
in a conforming way.

Recapping, the issue is: "on the client, how do you do you specify a port
forward that listens on the IPv4 and IPv6 loopacks on the server (ie by passing
a hostname of NULL and hint of AI_PASSIVE to getaddrinfo)."

The spec currently says:
[quote]
byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward"
boolean want reply
string address to bind (e.g., "0.0.0.0")
uint32 port number to bind

The 'address to bind' and 'port number to bind' specify the IP
address and port to which the socket to be listened is bound. The
address should be "0.0.0.0" if connections are allowed from anywhere.
[/quote]

There was also a proposal from Niels Möller
(http://thread.gmane.org/gmane.ietf.secsh/2273) to use the string to "" to
specify listening on any address, although it appears that no consensus was reached.

As I read the spec, the options for the client currently are:
1) specify an address string of "127.0.0.1"
2) specify an address string of "localhost"

and optionally in the server
3) special-case a string of "localhost" to mean calling getaddrinfo with a host
of NULL and AI_PASSIVE in the hints.

1) is more likely to work since it doesn't rely on a nameservice, however 2)
will probably give you both IPv4 and IPv6 loopbacks if the host supports them.

Since 2) depends on the nameservice, however it seems that using it for this
introduces another point of attack (ie if the server doesn't have 'localhost' in
its hosts file, and an attacker spoofs 'localhost.example.com' to be the host's
external IP, other users may unknowingly be binding their port forwards to the
external address.

Because of this, I'm leaning towards option 1). It's consistent with the
current spec of "0.0.0.0" for wildcard bind (ie it's equivalent to what you'd
see from netstat for IPv4 only). Opinions sought.

Thinking about it, I wonder if the spec should say that a string of "" means
"bind to whatever loopbacks you have" and a string of "*" means "bind to every
address family you support".




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #782 is|0 |1
obsolete| |




------- Additional Comments From dtucker@zip.com.au 2005-01-24 16:48 -------
Created an attachment (id=783)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=783&action=view)
forward-bind.sh: regression test for binding port forwards to addresses

Now with backwards compatibility testing and a free set of steak knives.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #666 is|0 |1
obsolete| |




------- Additional Comments From dtucker@zip.com.au 2005-01-24 17:17 -------
Created an attachment (id=784)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=784&action=view)
Update patch to OpenBSD -current

Update patch to -current (fixed trivial breakage on usage, otherwise
unchanged).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-28 12:30 -------
OK, here is a concrete proposal and a rationale:

I don't think the risks of sending "localhost" are too great; if a system is so
badly misconfigured to be susceptible to attack via this method, then it has far
greater problems than we can work around. Anyway, it isn't a common problem (see
below.)

Special-casing "0.0.0.0" and "127.0.0.1" seems ugly: if we do that they how can
you remotely specify an IPv4-only listener for any or loopback?

So, I think:

1. The server should special-case the empty string to be a wildcard (NULL,
AI_PASSIVE) bind
2. The server should special-case "localhost" to be a loopback (NULL, 0) bind
3. The client should send the empty string for wildcard binds
4. The client should send "localhost" for loopback binds

Some interoperabiliy considerations of this approach

a. For OpenSSH old client, OpenSSH new server

The client always sends "0.0.0.0", so this will break IPv6 for
the gateway_ports case.

b. For OpenSSH new client, OpenSSH old server

The server doesn't care what is sent, so this will work (as far as it works now,
anyway).

c. For other client, OpenSSH new server

OpenSSH sshd will do what the client tells it to :) Potential problems as per
"a" above.

d. For OpenSSH new client, other server

This is the only case there Darren's concern over the sending of "localhost"
manifests, because OpenSSH hasn't (and won't) interpret the name.

We may break gateway_ports rforwards on other servers if they haven't
special-cased the empty string to mean a wildcard bind. An easy workaround is to
just specify a bind address manually




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-29 12:34 -------
The regress tests should test SSHv1 connections too.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-29 13:18 -------
(From update of attachment 784)
>Index: ssh.c
>===================================================================
>RCS file: /cvs/src/usr.bin/ssh/ssh.c,v
>retrieving revision 1.230
>diff -u -p -r1.230 ssh.c
>--- ssh.c 7 Nov 2004 17:57:30 -0000 1.230
>+++ ssh.c 24 Jan 2005 06:15:41 -0000

...

>@@ -845,14 +866,19 @@ ssh_init_forwarding(void)
>
> /* Initiate remote TCP/IP port forwardings. */
> for (i = 0; i < options.num_remote_forwards; i++) {
>- debug("Connections to remote port %d forwarded to local address %.200s:%d",
>- options.remote_forwards[i].port,
>- options.remote_forwards[i].host,
>- options.remote_forwards[i].host_port);
>+ listen_host = options.remote_forwards[i].listen_host;
>+ if (listen_host && listen_host[0] == '\0' && !options.gateway_ports)
>+ listen_host = NULL;

This check looks bogus: it is trying to apply the client's gateway_ports
setting to remote forward sent to the server. I think it should be removed,
right?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-29 13:25 -------
(In reply to comment #25)
> This check looks bogus: it is trying to apply the client's gateway_ports
> setting to remote forward sent to the server. I think it should be removed,
> right?

I think it's valid. It seems intutive to do:
$ ssh -oGatewayPorts=yes -R 1234:foo.example.com:1234 server
and expect it to be a wildcard listen (server permitting, of course).

Using the client's GatewayPorts as the default for requests sent to the server
too seems sane. It can always be overridden per-forward with something like -R
*:1234:foo.example.com:1234 or -R localhost:1234:foo.example.com:1234.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-29 13:29 -------
I don't like it because it controls for -L port forwards as well and we don't
want to encourage people to put "GatewayPorts yes" at the top of their
ssh_config just to change the remote default.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-29 13:43 -------
It also means there's no way to turn it on per-host if that's what you really want.

I don't mind much either way, as long as the documentation is clear (and you
field any "GatewayPorts doesn't work with remote forwards" bug reports :-)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-29 13:59 -------
(In reply to comment #28)
> It also means there's no way to turn it on per-host if that's what you really
want.

I think your can:

$ ssh -R:8000:localhost:80 foo
$ ssh -R*:8000:localhost:80 foo
-> enables wildcard listen on the server (modulo the server's gateway_ports setting)

$ ssh -R 8000:localhost:80 foo
-> defaults to localhost listen on the server

Am I missing something?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #784 is|0 |1
obsolete| |




------- Additional Comments From djm@mindrot.org 2005-01-29 14:01 -------
Created an attachment (id=791)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=791&action=view)
Latest version

Latest version. Incorporates suggested special-case address_to_bind strings,
adds KNF and fixes a few bugs.

(i'll get interdiff set up on bugzilla soon so it will be possible to see
changes between these diffs)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-29 14:22 -------
(In reply to comment #29)
> $ ssh -R 8000:localhost:80 foo
> -> defaults to localhost listen on the server

Yeah, but right now that defaults to a wildcard listen on the server, modulo
GatewayPorts on the server. (Whether or not this is a good idea is another
matter, but that's what it does right now.) Checking the client's GatewayPorts
would be one way of maintaining the current behavior if that's what they really
wanted.

Maybe GatewayPorts on the client could have another couple of options?
GatewayPorts yes | no | clientonly | serveronly




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-29 16:32 -------
(In reply to comment #31)

I don't think we need a new option for this. We can either:

1. Retain the current behaviour of rforwards to a server with gatewayports=yes
being wildcard by default.

2. Change the behaviour and document it.

I like (2) because we have the opportunity to present a safer default, but we
wouldn't be going backwards if we did (1).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker@zip.com.au 2005-01-29 16:50 -------
(In reply to comment #32)
> I like (2) because we have the opportunity to present a safer default, but we
> wouldn't be going backwards if we did (1).

Except that there's more incentive to enable GatewayPorts=yes on the server
since per-interface binds are potentially more useful.

I dunno. "Secure by default" when in doubt?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From djm@mindrot.org 2005-01-29 23:46 -------
Created an attachment (id=792)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=792&action=view)
Man page updates

nroff is pain.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #791 is|0 |1
obsolete| |
Attachment #792 is|0 |1
obsolete| |




------- Additional Comments From djm@mindrot.org 2005-02-09 15:06 -------
Created an attachment (id=806)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=806&action=view)
Latest diff

This is the current version of the diff, including a couple of small changes
suggested by dtucker@



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #806 is|0 |1
obsolete| |




------- Additional Comments From djm@mindrot.org 2005-02-22 10:45 -------
Created an attachment (id=834)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=834&action=view)
Revised patch

Revise the patch again, based on comments from markus@

Among a few other tweaks, this patch adds manpage descriptions for the extra
arguments for -L and LocalForward. It also special-cases the bind_address
"0.0.0.0" for older OpenSSH versions, which will retain the current behaviour
for the old client + new server case.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


djm@mindrot.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED




------- Additional Comments From djm@mindrot.org 2005-03-01 21:25 -------
Patch applied. Thanks to all who helped.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport [ In reply to ]
http://bugzilla.mindrot.org/show_bug.cgi?id=413


dtucker@zip.com.au changed:

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




------- Additional Comments From dtucker@zip.com.au 2005-03-10 09:07 -------
With the release of OpenSSH 4.0, these bugs are now closed. For details, see:
http://www.openssh.com/txt/release-4.0



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.