Re: Incorrect protocol implementation by OpenSSH?

In article <pan.2007.09.27.17.59.40@xxxxxxxxx>,
H.K. Kingston-Smith <HKK-S@xxxxxxxxx> wrote:
Why? I can't believe that OpenSSH does not implement
SSH_MSG_CHANNEL_FAILURE message processing - this message is most
certainly contemplated in the standard. It is true that the
SSH_MSG_CHANNEL_REQUEST message sent by the OpenSSH client contains a 0
byte in the want-reply field. However, my interpretation of the relevant
portion of the standard (RFC 4254, section 5.4) is that the server should
send an SSH_MSG_CHANNEL_FAILURE message in this case regardless of the
contents of the want-reply field.

That interpretation is incorrect. The RFC says:

If 'want reply' is FALSE, no response will be sent to the request.
Otherwise, the recipient responds with either
SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific
continuation messages. If the request is not recognized or is not
supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.

The "Otherwise" obviously qualifies its own sentence, but it implicitly
qualifies the last sentence as well.

This is clear if you think about how responses to
SSH_MSG_CHANNEL_REQUESTs are matched up with the requests. They don't
have sequence numbers, so the only way to match them up is to count the
number of requests (with 'want reply' true) and responses. If requests
with 'want reply' false could generate SSH_MSG_CHANNEL_FAILURE, it would
be impossible to reliably pair up requests and responses.

What OpenSSH should really do is disconnect with
SSH_DISCONNECT_PROTOCOL_ERROR, but emitting SSH_MSG_UNIMPLEMENTED isn't
surprising. PuTTY would probably do such a thing in equivalent
circumstances, though now that I've noticed it I might try to correct
that.

Is this not the correct interpretation? The PuTTY client (at
least version 0.60) does seem to agree, for it just terminates the
connection at that point without sending any SSH_MSG_UNIMPLEMENTED
messages.

PuTTY sets 'want reply' to true, since it unsurprisingly cares whether
the request for a command succeeded. Thus it's expecting an
SSH_MSG_CHANNEL_SUCCESS or an SSH_MSG_CHANNEL_FAILURE.

--
Ben Harris
.

Relevant Pages

  • Re: Mixed Sync/Async communications pattern
    ... responses, but someone may already have solved the problem. ... after which the requests gathered so far would be sent off in a ... into a dict or similar. ... proc something:real {state env} { ...
    (comp.lang.tcl)
  • Re: Bandwidth constraint causing IIS/ASP.NET problem
    ... > We simulated too many clients, making requests faster than the ... > bandwidth on that part of the network could consume the responses. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Dont BOUNCE the list!
    ... I have received responses regarding filtering (requests for ... filtering, requests for greater granularity, requests for whitelists) ... The typical response is "We don't ...
    (Security-Basics)
  • Re: Windows 2003 external nslookup times out, internal works
    ... My firewall does not log responses to DNS (or any other ... ports), only the initial requests. ...
    (microsoft.public.windows.server.dns)
  • Re: ASP Takes Over The Server
    ... > This occuring when no one is on the application, it is like some sort of ... The aspnet_wp process primarily handles requests and responses. ... I suggest checking the IIS logs and system event logs. ...
    (microsoft.public.dotnet.framework.aspnet)