2007/11/26, Dan Fandrich wrote:

> runtests.pl has just been updated to stop binding the socks server to
> localhost when started because doing so didn't work on some platforms.

The change done avoids explicit specification of the bind address part
for the local sockserver port. Yes, because doing so didn't work on
some platforms.

> Unfortunately, this opens up a security hole on all systems running the
> curl test suite. The socks port becomes open to all systems and on
> machines facing the open Internet, [...]

I'm not so sure this creates a security hole.

http://www.openbsd.org/cgi-bin/man.cgi?query=ssh (-D [bind_address:]port)

When no explicit specification of the bind address part for the local
sockserver port is given the port is bound in accordance with the
GatewayPorts setting

http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current
(GatewayPorts)

Specifies whether remote hosts are allowed to connect to local
forwarded ports. By default, ssh(1) binds local port forwardings to
the loopback address. This prevents other remote hosts from
connecting to forwarded ports. GatewayPorts can be used to specify
that ssh should bind local port forwardings to the wildcard address,
thus allowing remote hosts to connect to forwarded ports. The
argument must be ``yes'' or ``no''. The default is ``no''.

And since our curl_ssh_config file does not specify the GatewayPorts
option, its default value is 'no' which prevents remote hosts from
connecting to forwarded ports.

This is my reasoning to state that I don't think that the change
introduces a security problem.

Even though, explicit "GatewayPorts no" could be added to
curl_ssh_config. But it should make no difference if it works as
documented.

Of course experimental facts override docs :-) So let's gather some...

Can you actually connect from another machine to the socksport and do
something ? Is it really wide open ?

-- 
-=[Yang]=-