Subject: [PATCH][WIP][v2] Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length

[PATCH][WIP][v2] Re: [SECURITY ADVISORY] Truncated Difffie-Hellman secret length

From: Yuriy M. Kaminskiy <>
Date: Thu, 25 Feb 2016 03:10:23 +0300

"George Garner (online)" <> writes:
> 3. Where is the p_len/group_order parameter validated? In
> kex_method_diffie_hellman_group_exchange_sha256_key_exchange it is
> converted from network byte order and accepted at face value. What
> happens if a malicious packet is received with a bogus value for
> p_len?

Maybe I miss something, but it looks like this defect (blindly trust
various 32-bit length that was sent remote side and don't verify if it
fits buffer) is *everywhere* in libssh2. I've sent some patches for
kex.c via gh pull request, but quickly discovered it is much worse. Very
WIP (and incomplete) patch for *other* files is attached; unfortunately,
in most cases, I have no idea how such errors should be handled within libssh2,
don't know libssh2 code base well enough, so I give up at this.

Note that in early connection setup "malicious server" is not required,
"malicious MITM" can insert broken packets as well.

In general, please re-review all `grep ntoh -r src/`, in many cases
surrounding code looks problematic in one way or other.


Received on 2016-02-26