A vulnerability was discovered in libssh2 before 1.9.0, kex_method_diffie_hellman_group_exchange_sha256_key_exchange in kex.c has an integer overflow that could lead to an out-of-bounds write in the way packets are read from the server. A remote attacker who compromises a SSH server may be able to execute code on the client system when a user connects to the server. This is related to an _libssh2_check_length mistake, and is different from the various issues fixed in 1.8.1, such as CVE-2019-3855.
Created libssh2 tracking bugs for this issue:
Affects: fedora-all [bug 1731325]
Upstream patch at: https://github.com/doorsdown/libssh2/commit/7e7189e013db15c6306fab0ddb38c020c0de81ed
Public reproducer: https://github.com/Semmle/SecurityExploits/tree/446048470633bf0f8da9570d008d056dbaa28ea9/libssh2/out_of_bounds_read_kex_CVE-2019-13115
This is an out-of-bounds read flaw in libssh2, which can be triggered by a malicious MITM SSH server. The flaw can be triggered during the initial Diffie-Hellman key change, therefore no authentication is required by the attacker. This flaw can cause applications compiled with libssh2 to crash.
However, I believe that a more carefully chosen offset could lead to an information disclosure as it appears that the memory which is read is subsequently returned to the server. The exploitability will depend on the heap layout.
In libssh2 versions after 1.8.2 the flaw exists in the function _libssh2_check_length(). Older versions however have no bounds checking at all, and the flaw manifests itself at: https://github.com/libssh2/libssh2/blob/02ecf17a6d5f9837699e8fb3aad0c804caa67eeb/src/kex.c#L1675
The problem is that p_len contains an untrusted value, so the subsequent reads from s could be out-of-bounds.
(In reply to Huzaifa S. Sidhpurwala from comment #2)
> Upstream patch at:
The above URL refers to some non-authoritative fork of the project. This seems to be the actual upstream commit: