www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Re: [libssh2] All Your Mem Belongs to Us

Re: [libssh2] All Your Mem Belongs to Us

From: David Robins <dbrobins_at_libssh2.org>
Date: Sat, 11 Nov 2006 00:42:13 -0800

On Friday November 10, 2006 05:23, James Housley wrote:
> On Nov 10, 2006, at 8:09 AM, Daniel Stenberg wrote:
...
> Okay. So does this look better?
> +
> + /* RFC4253 section 6.1 Maximum Packet Length says:
> +
> + "All implementations MUST be able to process
> packets with
> + uncompressed payload length of 32768 bytes or
> less and
> + total packet size of 35000 bytes or less
> (including length,
> + padding length, payload, padding, and MAC.)."
> +
> + */
> + if(packet_length > THE_DANIEL_STENBERG_CONSTANT) {
> + return -1;
> + }
> +
>
> Maybe that name needs a little work.
>
> Maybe MAX_SSH_PACKET_LEN would be better.

But it's not the maximum packet length. It's actually the minimum "maximum length" for conforming applications. The full text of RFC 4253 section 6.1 is:

6.1. Maximum Packet Length

   All implementations MUST be able to process packets with an
   uncompressed payload length of 32768 bytes or less and a total packet
   size of 35000 bytes or less (including 'packet_length',
   'padding_length', 'payload', 'random padding', and 'mac'). The
   maximum of 35000 bytes is an arbitrarily chosen value that is larger
   than the uncompressed length noted above. Implementations SHOULD
   support longer packets, where they might be needed. For example, if
   an implementation wants to send a very large number of certificates,
   the larger packets MAY be sent if the identification string indicates
   that the other party is able to process them. However,
   implementations SHOULD check that the packet length is reasonable in
   order for the implementation to avoid denial of service and/or buffer
   overflow attacks.

Note: "implementations SHOULD support longer packets, where they might be needed." It's fine to clamp the length, but a larger maximum could be chosen.

-- 
David Robins
Received on 2006-11-11

the libssh2 team