[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reg: libSSH0.6.0 Issue faced during ssh_channel_write


Hi Aarthi,

(Please do not add support@xxxxxxxxxx in the CC if you do not want/have
commercial support).
I ack that there's something not right in "bad packet length", but the
snippets of code that you showed me are perfectly normal. We prepend
every packet with its Hmac and do encryption in-buffer to spare space.

Could you please share with us:
- Do this message happen every time or only on some servers, or a few
connections ?
- Please enable verbosity logging so we have more context. Please paste
the whole session.
- Do you use multithreading ? If so, how do you use it with libssh ?
- Does this message happen on server side or client side ? re-reading
your email for the 5th time I only begin to think this message may have
been generated by openssh. If so, please run openssh in full debugging
mode (-ddd).

> 
> we compare the "len" against "length" we see a difference here . where we expect the values to be same.
> Sometimes the value of "length"is 0  - which could be because of packet not getting encrypted.
> We suspect because of this variance the packet gets a bad length and hence the reason for the error.
I think at that moment the packet buffer is not valid anymore. The
ssh_socket_write function is called from a callback in an asynchronous
way and it's very possible that it doesn't write a whole packet as once.
Whatever is happening here is not relevant, because your error seemed to
be client-side.

Aris

Le 10/03/14 15:25, aarthit 2014 a écrit :
> Hi,
> 
> We have integrated libssh to our product and we face the bad packet
> length and packet integrity error when we try to establish the ssh session.
> (We tried with both 0.6.0 and 0.6.3)
> 
> Issue description:
> 
> *Bad packet length 210610402.
> Disconnecting: Packet corrupt*
>  
> while connecting we get the above error on the client side.
> On debugging we could see
> There is a change in the length of the session->out_buffer in the
> function packet_send2
> 
> For debugging we added  a var say " length" to the structure ssh_buffer.
> 
> We store the value of the len after calling the encrypt function into
> this length variable.
> 
> In*packet_send2* function we save the length after
> 
> memcpy(data, out, len);
> 
> “length” is incremented by 20 in the snippet
> 
> *
> *
> 
> *if (hmac) {*
> 
> *    if (buffer_add_data(session->out_buffer, hmac, 20) < 0) {*
> 
> *   // code added to inc “length” by 20*
> 
> *   session->out_buffer->length +=20;
> *
> 
> *      goto error;*
> 
> *    }*
> 
> * *
> 
> 
> we print the length here in this function and in ssh_socket_write
> 
> int ssh_socket_write(ssh_socket s, const void *buffer, int len) {
> 
> 
> we compare the "len" against "length" we see a difference here . where
> we expect the values to be same.
> Sometimes the value of "length"is 0  - which could be because of packet
> not getting encrypted.
> We suspect because of this variance the packet gets a bad length and
> hence the reason for the error.
> 
> 
> Questions:
> 
> 1.       Buffer is getting accessed/modified using the routines
> buffer_add_*(buffer_add_u32, buffer_add_u16 etc)
> 
> 2.       Out_buffer is global for a session.
> 
> 3.       The out_buffer gets modified after encryption. So the packet
> can have invalid contents.
> 
> Kindly Share your thoughts. This could be a race condition.
> 
> 
> Please let us know if there is a way to to protect it.
> 
> 
> 
> Thanks
> 
> Aarthi
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Mar 7, 2014 at 2:11 PM, aarthit 2014 <aarthit2014@xxxxxxxxx
> <mailto:aarthit2014@xxxxxxxxx>> wrote:
> 
>     Hi ,
> 
> 
>     We have libssh 0.6.0 integrated to our product and while
>     establishing a SSH session we see the following client side error
>     and the session gets disconnected.
> 
>     *Bad packet length 210610402.
>     Disconnecting: Packet corrupt*
> 
>     And sometimes
> 
>     *Packet integrity error *
> 
>     On debugging I could see that in function ssh_packet_send2 when ever
>     the payload is 0 , we are hitting this case.
>     And I am not aware why payload becomes 0 all of a sudden.
> 
> 
>     This issue is not seen consistently, but on opening multiple
>     sessions we get this error in one of the sessions.
> 
> 
>     Please let us know what could be reason for this packet corruption.
> 
> 
>     Thanks
>     Aarthi
> 
> 
> 
>     On Wed, Mar 5, 2014 at 1:58 PM, aarthit 2014 <aarthit2014@xxxxxxxxx
>     <mailto:aarthit2014@xxxxxxxxx>> wrote:
> 
> 
> 
>         Forwarded conversation
>         Subject: *Reg: libSSH0.6.0 Issue faced during ssh_channel_write*
>         ------------------------
> 
>         From: *aarthit 2014* <aarthit2014@xxxxxxxxx
>         <mailto:aarthit2014@xxxxxxxxx>>
>         Date: Tue, Mar 4, 2014 at 7:39 PM
>         To: support@xxxxxxxxxx <mailto:support@xxxxxxxxxx>
> 
> 
>         Hi,
> 
> 
>         We have integrated libSSH-0.6.0 to our product and using it as a
>         SSH server.
>         we face an issue while running a script which only displays the
>         help options that we use in our product over a SSH session.
> 
>         In this script we open a SSH session and run the help commnad
>         for an iteration of more than 5000 times sequentially (command
>         executed one by one).
> 
>         The help command will just display the options available for our
>         product and the number of the characters in each set would be
>         approximately 735 characters.
> 
> 
>         In this process we face the following error:
> 
>         The session gets hanged when we run the script and there is no
>         response from the script.
> 
>         On addition of debugs we see that the ssh_channel_write and
>         correspondingly calls the ssh_blocking_flush function we do not
>         get a proper return value out of this function whereas the
>         ssh_handle_packets_termination function returns 0. There is some
>         kind of hang that is happening while flushing the data.
> 
>         Correspondingly in our interface code we see that the write
>         Mutex that was fetched was not getting released because of the
>         non response from the flush channel function.
> 
>         Is there any specific reason why the packets are not flushed
>         properly. But we donot see any packet errors in case of the
>         session hang, the session hangs abruptly.
> 
> 
>         Normally the script runs successfully for a trial of 100 to 1000
>         and even 2000 times . But when we run for more than 5000
>         iterations we face this issue, Is there a buffer restriction or
>         specific limit that ssh_channel_write can happen.
> 
> 
>         Kindly help us in this regard, let us know if there are any
>         solution available for this.
> 
> 
>         Thanks
>         Aarthi
> 
>         ----------
>         From: *Andreas Schneider* <asn@xxxxxxxxxxxxxx
>         <mailto:asn@xxxxxxxxxxxxxx>>
>         Date: Tue, Mar 4, 2014 at 10:19 PM
> 
>         To: aarthit 2014 <aarthit2014@xxxxxxxxx
>         <mailto:aarthit2014@xxxxxxxxx>>, support@xxxxxxxxxx
>         <mailto:support@xxxxxxxxxx>
> 
> 
>         On Tuesday 04 March 2014 19:39:04 you wrote:
>         > Hi,
> 
>         Hello,
> 
>         > We have integrated libSSH-0.6.0 to our product and using it as
>         a SSH server.
>         > we face an issue while running a script which only displays
>         the help
>         > options that we use in our product over a SSH session.
> 
>         great that you use libssh. Did you try version 0.6.1 or 0.6.3
>         already? I
>         thought that we already have fixed and issue with
>         ssh_channel_write().
> 
> 
>         It would be great if you send such questions to the mailing
>         list. More people
>         will see it and are able to response with their expertise.
> 
> 
>         If it is not fixed. We need to see some parts of the code or a
>         reproducer.
> 
> 
>         Regards,
> 
> 
>                 -- andreas
> 
>         --
>         Andreas Schneider                   GPG-ID: CC014E3D
>         www.cryptomilk.org <http://www.cryptomilk.org>              
>          asn@xxxxxxxxxxxxxx <mailto:asn@xxxxxxxxxxxxxx>
> 
> 
>         ----------
>         From: *aarthit 2014* <aarthit2014@xxxxxxxxx
>         <mailto:aarthit2014@xxxxxxxxx>>
>         Date: Wed, Mar 5, 2014 at 12:43 PM
>         To: Andreas Schneider <asn@xxxxxxxxxxxxxx
>         <mailto:asn@xxxxxxxxxxxxxx>>
>         Cc: support@xxxxxxxxxx <mailto:support@xxxxxxxxxx>
> 
> 
>         Hi,
> 
>         Thank you for the response.
> 
>         We downloaded the version 0.6.3 and even in this we are facing
>         the issue. Could you please tell us if a similar kind of issue
>         was fixed in ssh_channel_write, When we compared 0.6.0 and 0.6.3
>         we do not see any specific changes in ssh_channel_write, or if
>         this issue was already fixed in version before 0.6.0.
> 
> 
>         Thanks
>         Aarthi
> 
>         ----------
>         From: *Andreas Schneider* <asn@xxxxxxxxxxxxxx
>         <mailto:asn@xxxxxxxxxxxxxx>>
>         Date: Wed, Mar 5, 2014 at 1:31 PM
>         To: aarthit 2014 <aarthit2014@xxxxxxxxx
>         <mailto:aarthit2014@xxxxxxxxx>>
>         Cc: support@xxxxxxxxxx <mailto:support@xxxxxxxxxx>
> 
> 
>         On Wednesday 05 March 2014 12:43:08 aarthit 2014 wrote:
>         > Hi,
> 
>         Hi,
> 
>         > Thank you for the response.
>         >
>         > We downloaded the version 0.6.3 and even in this we are facing
>         the issue.
>         > Could you please tell us if a similar kind of issue was fixed in
>         > ssh_channel_write, When we compared 0.6.0 and 0.6.3 we do not
>         see any
>         > specific changes in ssh_channel_write, or if this issue was
>         already fixed
>         > in version before 0.6.0.
>         >
> 
>         you probably found a bug then. You should read
> 
>         http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
>         <http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html>
> 
> 
>         and open a bug at https://red.libssh.org/
> 
> 
>         If possible, create a reproducer or show some code snippets how you
>         implemented it.
> 
> 
>         Thanks,
> 
> 
> 
> 
> 
> 

Archive administrator: postmaster@lists.cynapses.org