Corrupted MAC on input

[Deron Meranda]

I was regularly seeing something similar back in July 2002.  Here's the
thread I started then,

http://www.mindrot.org/pipermail/openssh-unix-dev/2002-July/014899.html

I never did get a reasonable answer.  I would see this with the server
running under HP-UX 11.0 with OpenSSH 3.4p1.  I have even seen it a
few times since, up to 3.7.1, although it's not nearly as often.  I
had always suspected it had something to so with HP, since I could
ssh into other linux boxes all day long without errors.

When I did see it, it didn't seem very random.  Doing certain things
like starting a tunneled X client would immediately cause it to occur.
Other times, the corrupted MAC would occur as soon as the session
would start, even before I could get a shell prompt.

At one point I started performing my own tests with lower and lower
levels of debuging, almost to the point of capturing all the raw
packet buffers just prior to encryption.  I even inserted extra debug
code so I could check every single step of the MAC computation and
verification.  I just could not explain what I saw, but it looked like
a single byte was always getting changed.  It was not a random pattern
at all.  If I recall correctly, I had ruled out the MAC computation
itself.  Also strangely the encrypted packets were identical.  But
somehow after decryption the plaintext buffers were different.  I hope
I'm recalling this correctly, but I think I am.

Unfortunately it's so rare now (with the newer versions), that it
would be very hard for me to redo those tests again.


I can tell you the most frustrating part is that the entire SSH
session is shut down on the first mismatched MAC.  I always wished the
protocol had a minimal amount of retry logic.

Deron Meranda