openssh bugs - Nov 2015 - [Bug 2509] New: Unexpected change in tcpip-forward reply message in OpenSSH 6.8

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

            Bug ID: 2509
           Summary: Unexpected change in tcpip-forward reply message in
                    OpenSSH 6.8
           Product: Portable OpenSSH
           Version: 6.8p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: ronf at timeheart.net

Today I tested my AsyncSSH client against OpenSSH 7.1 and noticed that
it had a problem with the reply message coming back from tcpip-forward.
After a bit of digging, I tracked down the change to OpenSSH 6.8 which
I think was part of the fix for bz#2147.

According to the OpenSSH spec:

   If a client passes 0 as port number to bind and has 'want reply' as
   TRUE, then the server allocates the next available unprivileged port
   number and replies with the following message; otherwise, there is
no
   response-specific data.

      byte     SSH_MSG_REQUEST_SUCCESS
      uint32   port that was bound on the server

OpenSSH 6.7 honors this, with there being no response-specific data in
the case where a non-zero port number is requested. The associated code
for this in server_input_global_request() in server loop.c is:

        if (want_reply) {
                packet_start(success ?
                    SSH2_MSG_REQUEST_SUCCESS :
SSH2_MSG_REQUEST_FAILURE);
                if (success && allocated_listen_port > 0)
                        packet_put_int(allocated_listen_port);
                packet_send();
                packet_write_wait();
        }

Note the test for "allocated_listen_port > 0". However, the new
code in
OpenSSH 6.8 does the following:

                if ((r = sshbuf_put_u32(resp, allocated_listen_port))
!= 0)
                        fatal("%s: sshbuf_put_u32: %s", __func__,
ssh_err(r));

and then later uses this "resp" buffer to create the response packet.
It puts the allocated_listen_port into the response unconditionally,
and so the end result is that requests for a non-zero port number
actually end up getting back a uint32 with a zero value in the response
instead of no data. This is causing a problem for AsyncSSH, as it
validates that there's no unexpected data at the end of the reply
packet, expecting this value only when it passes a port number of 0 in
the request.

Since I only noticed this now and it's present in OpenSSH 6.8, 6.9,
7.0, and 7.1, I'm probably going to need to relax my check and allow
this value to be ignored, at least for the affected OpenSSH versions.
However, I think this should be fixed to match the spec and omit the
port in the reply when a dynamic port is not allocated.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
             Blocks|                            |2451

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Thanks for the detailed report, I've just committed a fix for OpenSSH
7.2

https://anongit.mindrot.org/openssh.git/commit/?id=b1d6b3971ef256a08692efc409fc9ada719111cc


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2451
[Bug 2451] Bugs intended to be fixed in 7.2
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.