ASA-2019-00574 – libssh2: Out-of-bounds read when connecting to a malicious SSH server

Allele Security Alert



ASA-2019-00574, CVE-2019-17498


Out-of-bounds read when connecting to a malicious SSH server


The libssh2 project



Affected version(s)

libssh2 version 1.9.0 and earlier

Fixed version(s)

libssh2 versions with the following commit applied:

packet.c: improve message parsing #402

Proof of concept



There is an out-of-bounds read vulnerability, potentially leading to either denial of service or remote information disclosure. It is triggered when libssh2 is used to connect to a malicious SSH server. The overflow occurs when the SSH server sends a disconnect message, which means that the vulnerability can be triggered early in the connection process, before authentication is completed.

Technical details

The source location of the vulnerability is packet.c:480:

if(message_len < datalen-13) {

The value of datalen is untrusted because it is controlled by the remote SSH server. If datalen == 11, for example, then the subtraction will overflow and the bounds check of message_len is ineffective. message_len is a 32-bit unsigned integer that is also controlled by the remote SSH server, so this can lead to an out-of-bounds read on line 485:

language_len =
_libssh2_ntohu32(data + 9 + message_len);

The out-of-bounds read will usually just cause a segmentation fault, but there is also potential for it to cause other kinds of harm in the call to LIBSSH2_DISCONNECT on line 499:

if(session->ssh_msg_disconnect) {
LIBSSH2_DISCONNECT(session, reason, message,
message_len, language, language_len);

It depends on how the libssh2 library is used, because session->ssh_msg_disconnect is a callback function that is null by default, but can be set by the user of the library (by calling libssh2_session_callback_set).


Kevin Backhouse (Semmle Security Research)


Another libssh2 integer overflow (CVE-2019-17498)

packet.c: improve message parsing #402

Out-of-bounds read in libssh2 (CVE-2019-17498)



If there is any error in this alert or you wish a comprehensive analysis, let us know.

Last modified: October 22, 2019

We are not responsible for any data loss, device corruption or any other type of issue due to the use of any information mentioned in our security alerts.