Subject: Re: Invalid channel numbers

From: [email-masked] (Peter Gutmann)
Date: Tue, 03 Aug 2004 01:19:49 +1200

Joseph Galbraith <[email-masked]> writes:

>The channel number is part of the packet that is predefined. Therefore, you
>can always parse the channel number, and send the response.

What if it's a channel open where the packet ends halfway through the channel
number?  You've got a request, there seems to be a requirement to send a
response, but you can't respond without some facility that lets you say "The
last channel-related request was disallowed".

Peter.

---

From: Jon Bright <[email-masked]>
Date: Mon, 02 Aug 2004 15:50:42 +0200

Hi,

> last channel-related request was disallowed".

This seems broken enough to just close the connection - it's not in 
accordance with the current spec, or any future possible altered spec. 
If you're really eager not to close the connection, sending an 
SSH_MSG_UNIMPLEMENTED might be a reasonable alternative.

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Markus Friedl <[email-masked]>
Date: Mon, 2 Aug 2004 15:44:04 +0200

On Tue, Aug 03, 2004 at 01:19:49AM +1200, Peter Gutmann wrote:
> number?

if you get a completely corrupt message, why not send a SSH_DISCONNECT_PROTOCOL_ERROR?

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 03 Aug 2004 02:33:25 +1200

>SSH_MSG_UNIMPLEMENTED might be a reasonable alternative.

Yeah, I guess that would do.  The reason why I'd prefer not to close the
connection outright is that there might he half a dozen data transfers
currently in progress, and I'd prefer not to abort them all just because of
one malformed packet on an unrelated channel.

Peter.

---

From: Simon Tatham <[email-masked]>
Date: Mon, 02 Aug 2004 15:44:18 +0100

> one malformed packet on an unrelated channel.

The question is, though, why would you _get_ such a malformed
packet? The SSH data channel is required to be free of corruption
and data loss (and the MACs enforce this vigorously), so it's not as
if half of an SSH message is going to routinely disappear en route.
The only way it can happen is as a result of a pretty fundamental
bug in the SSH implementation at the far end.

Therefore, it isn't unreasonable to assume that an SSH
implementation which has sent you a packet that badly formed is in a
state of total internal confusion, and to terminate the connection
before it sends you any more plausible rubbish that you might
accidentally trust!

I can't imagine any situation in which this sort of error condition
would occur routinely, such that it would make sense to spend effort
on salvaging everything possible from the rest of the SSH
connection. It really ought to only ever occur when the client or
server is in development, in which case you weren't transferring any
important data through it anyway.
-- 
Simon Tatham         What do we want?        ROT13!
<[email-masked]>   When do we want it?     ABJ!

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 02 Aug 2004 14:19:19 -0400

> last channel-related request was disallowed".

so, my sense is that there will always be a level of peer-brokenness
for which the only possible recovery is for the implementation to
throw up its virtual hands and give up.  This bit of the protocol runs
on top of an integrity-protected channel; a parse error either
indicates a buggy peer, buggy integrity protection, or a bug in your
own implementation, and distinguishing these cases is hard.

exactly how hard you try to keep going before that is something of a
quality-of-implementation issue.  dropping the connection seems like an
entirely reasonable response..

					- Bill

---

From: Markus Friedl <[email-masked]>
Date: Mon, 2 Aug 2004 17:41:23 +0200

> before it sends you any more plausible rubbish that you might

i can only agree with you, and this is why i'd prefer
SSH_DISCONNECT_PROTOCOL_ERROR.

---

From: [email-masked] (Niels Möller)
Date: 19 Aug 2004 16:48:34 +0200

> last channel-related request was disallowed".

I don't see any problem here. Whenever you receive a packet that
clearly doesn't follow the spec, just reply with SSH_MSG_DISCONNECT,
SSH_DISCONNECT_PROTOCOL_ERROR, then hang up the connection. Truncated
channel requests are in this class.

If you *really* want to be more forgiving than that, send a
SSH_MSG_DEBUG explaining the problem, and then ignore the packet. But
such behaviour goes beyond the specification. My reading of the spec
is that SSH_MSG_DISCONNECT is the only appropriate response in this
case.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 31 Aug 2004 11:47:03 -0700 (PDT)

Hi,

Just following up on this.  I believe that no editing needs to go into any
of the documents from this discussion.  Does anyone disagree with that?

Thanks,
Chris

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 31 Aug 2004 15:03:16 -0400

> of the documents from this discussion.  Does anyone disagree with

So, my sense:

Clear consensus is that there is no need for any protocol changes as a
result of this discussion.

If someone wants to improve the existing text on error handling
(fitting Niels's first paragraph on error handling into the spec),
they should do so now but I don't believe it's critical.

						- Bill