Handling recv oversized packets

[Smith, JDave]

Thanks for the info Stuart

I must admit I did not think to take off our standard disclaimer before sending out this message as an email to the mail distributer. I think I have learnt my lesson - thanks...

As I said, I went looking in common_channel.c and spotted

    678 /* Shared for data and stderr data - when we receive data, put it in a buffer
    679  * for writing to the local file descriptor */
    680 void common_recv_msg_channel_data(struct Channel *channel, int fd,
    681 		circbuffer * cbuf) {
     :
    701 	datalen = buf_getint(ses.payload);
    702 	TRACE(("length %d", datalen))
    703 
    704 	maxdata = cbuf_getavail(cbuf);
    705 
    706 	/* Whilst the spec says we "MAY ignore data past the end" this could
    707 	 * lead to corrupted file transfers etc (chunks missed etc). It's better to
    708 	 * just die horribly */
    709 	if (datalen > maxdata) {
    710 		dropbear_exit("Oversized packet");
    711 	}

As I said, I am not a coding expert and I really want to be proved wrong. So is the above not applicable to my concern?

JD

PS. Do you really still use tape for backups, my head is in the clouds ;-)

-----Original Message-----
From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On Behalf Of Stuart Longland
Sent: 06 September 2011 23:47
To: dropbear at ucc.asn.au
Subject: Re: Handling recv oversized packets

Before I answer, one point I'd like to raise:
> This communication contains information which is confidential and may
> also be privileged. It is for the exclusive use of the addressee. If you
> are not the addressee please note that any distribution, reproduction,
> copying, publication or use of this communication or the information is
> prohibited. If you have received this communication in error, please
> contact us immediately and also delete the communication from your
> computer. We accept no liability for any loss or damage suffered by any
> person arising from use of this email.

The above being the case, why on EARTH did you send this to a PUBLIC
mailing list?

It's like ringing up on a national talk-back radio show then telling the
announcer, having just spoken to them on air for about 2 minutes, that
what you've told everyone listening on the air is private between you
and the announcer only, not to be rebroadcast.

Commercial in-confidence information has no place on such a mailing
list, and such walls-of-text as those above, look utterly ridiculous in
such a forum.

I will proceed to answer, ignoring the above, as it is widely publicised
that this mailing list goes to multiple undisclosed parties and is also
archived for world-wide perusal.  If there are any commercial
ramifications, they are your problem, not mine as you were warned.

(Okay... now to dismount from this soap box...)

On 09/07/11 07:09, Smith, JDave wrote:
> Hi
>  
> What happens if a received SSH packet is greater than the max length for
> received packets? From something I have seen in the code
> (common-channel) I am concerned that this causes dropbear to simply
> terminate. My concern is that this leaves dropbear implementations open
> to DOS attacks. I am not an expert in C and the code I have checked is
> v0.52 so I may be wrong or not up-to-date...

I'd be curious to know where you're looking.  No doubt others more
knowledgeable about the code will probably know exactly where to look
for the answer, but if I read this correctly:

http://cvs.ucc.asn.au/cgi-bin/viewvc.cgi/anoncvs/projects/dropbear/channel.c?view=markup
> 701 	/* if the client is going to send us more data than we've allocated, then
> 702 	* it has ignored the windowsize, so we "MAY ignore all extra data" */
> 703 	maxdata = channel->writebuf->size - channel->writebuf->pos;
> 704 	if (datalen > maxdata) {
> 705 	    TRACE(("Warning: recv_msg_channel_data: extra data past window"));
> 706 	    datalen = maxdata;
> 707 	}

then the situation is handled by *ignoring* the extra data.

> Note that we have a customer who is extremely security conscious and
> would view this as an issue, and since security considerations are on
> the rise in the market they would probably not be alone (at least not
> for very long).

They certainly aren't... and I'm happy to be corrected on my assessment above.

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.