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: James Housley <jim_at_thehousleys.net>
Date: Sat, 11 Nov 2006 06:52:03 -0500

On Nov 11, 2006, at 3:42 AM, David Robins wrote:

> 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.

Correct. It looks like the key is "... the larger packets MAY be
sent if the identification string indicates that the other party is
able to process them. ..." So if libssh2 does not say that it can
handle larger packets we should be fine. Then from the example
several packets would be needed for the "very large number of
certificates", right?

Jim

--
/"\   ASCII Ribbon Campaign  .
\ / - NO HTML/RTF in e-mail  .
  X  - NO Word docs in e-mail .
/ \ -----------------------------------------------------------------
jeh@FreeBSD.org      http://www.FreeBSD.org     The Power to Serve
jim@TheHousleys.Net  http://www.TheHousleys.net
---------------------------------------------------------------------
In theory there is no difference between theory and practice.
In practice there is no similarity.
       -- From the "I wish I'd said that" archives.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
libssh2-devel mailing list
libssh2-devel_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
Received on 2006-11-11

the libssh2 team