"George Garner (online)" <ggarner_online_at_gmgsystemsinc.com> 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.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel