[Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=413





------- Additional Comments From dtucker at 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.