Re: Server woes - Bad packet length, corrupted MAC on input

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi Jeetu,

I agree with you that this is a low-level problem in libssh. In the
beginning I've though of a multithreading issue but apparently you
removed that part of the equation.
Do you have a little scenario that I can use to reproduce the problem ?
Which protocols have been in use ? (ecdh/dh-group1/aes128-ctr/zlib)

A verbose log of the SSH client (openssh) when it happens would be very
helpful, to see if they send some kind of packet.

We need to track that bug and smash it.

Thanks,

Aris

Le 17/10/11 21:02, jeetu.golani@xxxxxxxxx a écrit :
> Hi guys,
> 
> Further to the HMAC error I've been seeing in my server
> implementation. I've also been noticing many scenarios wherein the
> OpenSSH client quits with either a "Bad packet length" or a "corrupted
> MAC on input"
> 
> I'm not sure if all ties in to the HMAC errors somehow.
> 
> From what I can see these errors (including HMAC) seem to be basically
> speaking of the integrity/state of the packet. Am I correct in
> assuming that this seems to hint at a lower level problem within
> libssh during creating the packets, encrypting and/or decrypting the
> packets than the server code which would basically just be routing
> information from the X client to the channel and vice versa. The
> server code now handles only a single session and is no longer
> multithreading and handling multiple sessions.
> 
> Thanks guys please let me know any thoughts. At this stage any
> suggestions would be deeply appreciated.
> 
> Bye for now
> 
> On Thu, Oct 13, 2011 at 7:04 PM, jeetu.golani@xxxxxxxxx
> <jeetu.golani@xxxxxxxxx> wrote:
>> Hi guys,
>>
>> As a few of you would remember I've been trying to build a libssh
>> based server. The primary features I've been interested in the server
>> are SSH authentication and X forwarding along with multithreaded
>> support.
>>
>> I've had mixed success with the implementation in the past as I have
>> reported here. After a long break (was off to CCC and had other things
>> I needed to clear up) I tried the new libssh master with my server
>> code. I reimplemented my server code for it to work with a single
>> session so as to try to minimize chances that multi-threading was
>> somehow causing things to bungle up.
>>
>> My X forwaded application fails after some usage. The failure shows up
>> with the application seemingly unable to refresh its window. I've
>> collected log information from libssh with verbosity set to
>> SSH_LOG_PACKET and put it up on pastebin -
>> http://pastebin.com/XpNWggGv
>>
>> The interesting segment seems to be:
>>
>> ...
>> [2011/10/13 17:26:00.712651, 2]   Channel receiving 32 bytes data in 0
>> (local win=1159472 remote win=2078764)
>> [2011/10/13 17:26:00.712687, 1]   placing 32 bytes into channel buffer
>> (stderr=0)
>> [2011/10/13 17:26:00.712722, 2]   Channel windows are now (local
>> win=1159440 remote win=2078764)
>> [2011/10/13 17:26:00.725785, 1] ssh_packet_socket_callback  Error:
>> read_packet(): Packet len too high(2488547759 945439af)
>> [2011/10/13 17:26:00.725890, 1] ssh_packet_socket_callback  Error: HMAC error
>> [2011/10/13 17:26:00.744160, 3]   Enabling POLLOUT for socket
>> [2011/10/13 17:26:00.744218, 3]   packet: wrote
>> [len=380,padding=6,comp=373,payload=373]
>> [2011/10/13 17:26:00.744233, 1]   channel_write wrote 364 bytes
>> [2011/10/13 17:26:17.172236, 1]   Socket exception callback: 1 (0)
>> [2011/10/13 17:26:17.172334, 1] ssh_socket_exception_callback  Error:
>> Socket error: Success
>>
>> This read_packet with a packet len that is too high with an HMAC error
>> seems to be consistent with results I had earlier.
>>
>> I am at a complete loss as to whether this and similar errors I've
>> seen are as a result of my code or a bug in libssh. If someone could
>> offer me thoughts as to which elements in my code could possibly be
>> causing this I could look into these elements and try and narrow
>> things down a little.
>>
>> I would sincerely appreciate some help in trying to resolve this.
>>
>> Thanks,
>> Jeetu
>>
>