[Bug 1818] New: SSH2_MSG_CHANNEL_FAILURE on closed channel

[bugzilla-daemon at bugzilla.mindrot.org]

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

           Summary: SSH2_MSG_CHANNEL_FAILURE on closed channel
           Product: Portable OpenSSH
           Version: 5.1p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: anakin at pobox.com


When I connect to an OpenSSH server using PuTTY with X11 forwarding,
and run a makefile I use which invokes a large number of X applications
in rapid succession, I find PuTTY terminates the session with a message
along the lines of "Disconnected: Received SSH2_MSG_CHANNEL_FAILURE for
nonexistent channel 257" (the channel number may vary).

I told PuTTY to produce a full session log, which I attach here. (Sorry
it's a bit large.) You can indeed see that PuTTY receives the final
SSH2_MSG_CHANNEL_FAILURE at a point when it has both sent and received
SSH2_MSG_CHANNEL_CLOSE on that channel. RFC 4254 section 5.3 states
that when a party has both sent and received SSH2_MSG_CHANNEL_CLOSE for
a channel, that channel is considered closed for that party and it may
reuse the channel number; PuTTY's indignation at receiving the
CHANNEL_FAILURE at that time therefore seems reasonable to me.

I think what must have happened is that OpenSSHD sent its CHANNEL_CLOSE
before it received the CHANNEL_REQUEST and CHANNEL_CLOSE from PuTTY; so
when _it_ received the CHANNEL_REQUEST, it had sent but not received
CHANNEL_CLOSE, and hence it did not yet consider the channel closed and
felt free to respond to the request.

However, although that sounds reasonable, I think it is in fact wrong
behaviour. I think a direct logical consequence of section 5.3 is that
after sending CHANNEL_CLOSE on a channel a party MUST NOT send any
subsequent responses to channel events - because it can't be sure the
other party hasn't just sent its own CHANNEL_CLOSE, causing exactly
this circumstance. Conversely, on receiving CHANNEL_CLOSE, a party must
discard any outstanding channel requests for which it was expecting to
receive responses, and assume those requests were not received by the
server until after it sent its close. I can't think of any other
interpretation of RFC 4254 devoid of race conditions.

(The channel request type is "winadj at putty.projects.tartarus.org": a
phony channel request designed to elicit a CHANNEL_FAILURE which PuTTY
uses to tune its window adjustment policy. I don't think that detail is
important except inasmuch as it has the want_reply flag set.)

I report this bug against 5.1p1, because that's the version in Debian
stable. However, I have reproduced the same behaviour with
openssh-SNAP-20100914 downloaded by following the links from
http://www.openssh.com/portable.html, so I don't think this is an
already-fixed issue.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.