> On host1, you open an ssh connection to a machine running sshd where
> you have a working account using -R (RemoteForward, which is
> somewhat the opposite of LocalForward, but behaves the same in this
> case) like this:
> host1$ ssh -R 65621:host1.com:80 victim.com
> (in this case, 65621 is equal to 2^16+85, i.e. port 85, the other ports
Some weeks ago I reported as a bug that sshd runs the port forwarder
as root, breaking identd queries. This exploit shows that it can lead
to even nastier problems.
I assume the main reason why sshd doesn't switch UIDs right after
authentication is the pty chown problem. But couldn't this be done by
the main sshd daemon using some sort of command channel to its
children? Then the first child sshd could run as user and avoid this
sort of problems.
> - This could also be considered a bug in bind(), because it doesn't wrap
> portnumbers > 65536, but still, it makes sshd vurnerable, at least on Linux
> (2.0.29), Solaris 2.4 and SunOs 4.1.4
No. bind(2) (and connect(2)) is called with a struct sockaddr_in as
argument, and this struct contains the port number as a 16-bit value
sin_port somewhere. The "wrapping" happens when the assignment to this
variable truncates the value to 16 bits.
I think (not tried) this particular bug can be fixed like this:
--- newchannels.c~
+++ newchannels.c
@@ -1397,4 +1397,5 @@
/* Get arguments from the packet. */
port = packet_get_int();
+ port &= 0xFFFF;
hostname = packet_get_string(NULL);
host_port = packet_get_int();
but the real underlying cause is that sshd does too much as root,
IMHO. Wonder what more problems of this kind could come up.
olaf