Libssh2 Download File BEST
Maria Haq
To add SSH support to IAP Desktop, I was lookingfor an SSH library that works on Windows, that can be used from .NET, and uses a liberal (non-GPL based) opensource license. Given these constraints, the list of suitable libraries quickly narrowed down toSSH.NET and libssh2.
Libssh2 is written in plain C and runs on many platforms. The library isa bit less feature-rich than its LGPL-basedcousin libssh, but it is well-maintained and relied on by countless open source tools such as curl. Compared to SSH.NET, libssh2 therefore seemed like the superior choice.
- Error -8140 (Execute Again Error, LIBSSH2_ERROR_EAGAIN) to a Warning 5040
- Package version number to match release version number
- Package name from `LIBSSH2` to `LIBSSH2 for LabVIEW` to further differentiate from the libssh2.org project
- Installation instructions to use VIPM.io links and procedures
Mariusz Ziulek reported that libssh2, a SSH2 client-side library, wasreading and using the SSH_MSG_KEXINIT packet without doing sufficientrange checks when negotiating a new SSH session with a remote server. Amalicious attacker could man in the middle a real server and cause aclient using the libssh2 library to crash (denial of service) orotherwise read and use unintended memory areas in this process.
The vulnerability exists in libssh2 version 1.8.2 and earlier. It is fixed in libssh2 version 1.9.0.I am not aware of any mitigations against this vulnerability, other than upgrading to version 1.9.0.
The vulnerability is an out-of-bounds read, potentially leading to a remote information disclosure.It is triggered when libssh2 is used to connect to a malicious SSH server.The overflow occurs during Diffie Hellman key exchange, which means that the vulnerability can be triggered early in the connection process, before authentication is completed.libssh2 receives a uint32_t from the malicious server and does no bounds checking on it.libssh2 then reads memory from the offset specified by the uint32_t.I have written a proof-of-concept exploit in which a malicious SSH server returns a very large offset value, which causes libssh2 to crash with a segmentation fault.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. Since libssh2 is only a library, this will vary depending on the application in which it is used.
On March 18, 2019, Chris Coulson of Canonical Ltd. disclosed nine vulnerabilities in libssh2(CVE-2019-3855 to CVE-2019-3863).Those vulnerabilities were fixed in libssh2 v1.8.1.At the time, my colleague Pavel Avgustinov noticed that the commit which fixed the vulnerabilities introduced several new alerts on LGTM.Those alerts were due to code like the following:
The problem is that _libssh2_get_c_string returns -1 as an error code, but p_len is unsigned, so the error condition will be ignored.It turned out that the libssh2 team had already fixed those issues in a later commit, but it prompted us to take a closer look at the code to see if it contained any other obvious bugs.We quickly discovered this badly implemented bounds check function:
I learned later (see timeline below) that _libssh2_check_length was introduced on the main development branch after the release of version 1.8.2, so this vulnerable bounds check does not exist in version 1.8.2.Unfortunately, version 1.8.2 contains no bounds check whatsoever, so the PoC still works.In version 1.8.2, the source location of the vulnerability is kex.c:1675.The problem is that p_len contains an untrusted value, so the subsequent reads from s could be out-of-bounds.Because _libssh2_check_length does not exist in version 1.8.2, there is no need for the value of p_len to be greater than 0x80000000 to trigger the bug.This means that much smaller values of len can trigger an out-of-bounds read, which means that the bug is much more likely to be exploitable to achieve remote information disclosure.
The query looks for functions which sometimes return a negative integer constant.For example, _libssh2_get_c_string does that on line 773.It then looks for calls to that function which take the return value and cast it to an unsigned type.
The libssh2 team posted a fix for the vulnerability on GitHub within a few days of receiving my report, but took almost 3 months to release a new version.This was partly due to a misunderstanding.When I sent them the PoC, I told them that the vulnerability was in revision 38bf7ce.It turns out that this revision was not included in the 1.8.2 release.So the libssh2 team fixed the bug on their development branch and considered it closed until I asked them for an update over a month later.The libssh2 team believed that 1.8.2 was not affected by the vulnerability, but I quickly discovered that my PoC also worked on version 1.8.2.They released the fix in version 1.9.0 without warning me, which is why I posted a hasty security advisory on twitter.
ppo libssh2-devel is already installed on your server. I'm not certain that it should be necessary to do so, but if the problem is that you're not able to locate the dev headers then try setting CPPFLAGS prior to running the build, eg:
df19127ead