A flaw was found in libssh client-side ProxyCommand handling. In sshsocketconnectproxycommand() in src/socket.c, the return value of fork() was not checked before being stored as the proxy child PID. If fork() fails, the value -1 can be retained in state and later used during cleanup, causing signals to be sent across the caller's accessible process tree. In deployments that use ProxyCommand, this can lead to local denial of service.

A flaw was found in libssh builds using the OpenSSL backend for AES-GCM. In the decrypt path in src/libcrypto.c, the return value from EVPDecryptFinal() was checked incorrectly, so authentication tag verification failures were not handled as integrity failures. This could effectively remove integrity protection for affected AES-GCM sessions and allow an in-path attacker to modify plaintext on the wire without detection.

A flaw was found in libssh client-side SFTP message handling. In sftpgetmessage() in src/sftpcommon.c, SFTP responses carrying unknown request IDs were accepted and kept queued instead of being rejected. A malicious SFTP server can repeatedly send responses for request IDs that were never issued by the client, causing unbounded growth of queued messages and leading to client-side memory exhaustion and denial of service.

A flaw was found in libssh channel data handling. In channelrcvdata() in src/channels.c, incoming channel DATA messages could still be processed after the channel had already been marked as remotely closed. In SFTP-backed applications and other callback-driven consumers, this creates a path where data callbacks may observe channel-associated state after it has already been torn down or freed, leading to crashes and possible use-after-free conditions.

A flaw was found in the libssh implements abstract layer for message digest (MD) operations implemented by different supported crypto backends. The return values from these were not properly checked, which could cause low-memory situations failures, NULL dereferences, crashes, or usage of the uninitialized memory as an input for the KDF. In this case, non-matching keys will result in decryption/integrity failures, terminating the connection.

A NULL pointer dereference was found In libssh during re-keying with algorithm guessing. This issue may allow an authenticated client to cause a denial of service.

libssh 0.9.4 has a NULL pointer dereference in tftpserver.c if sshbuffernew returns NULL.

External Reference:

https://bugs.gentoo.org/734624

libssh before 0.7.3 improperly truncates ephemeral secrets generated for the (1) diffie-hellman-group1 and (2) diffie-hellman-group14 key exchange methods to 128 bits, which makes it easier for man-in-the-middle attackers to decrypt or intercept SSH sessions via unspecified vectors, aka a "bits/bytes confusion bug."

The (1) SSHMSGNEWKEYS and (2) SSHMSGKEXDHREPLY packet handlers in packagecb.c in libssh before 0.6.5 do not properly validate state, which allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a crafted SSH packet.

Description of problem:

Maybe it is possible to send a malicious kexinit package to eventually cause a server to a double-free.

I guess this is only a DoS.

Source code:

http://git.libssh.org/projects/libssh.git/

Patch:

From f6b9f851b962e3a587f3f99b7cb97d130f0c77b9 Mon Sep 17 00:00:00 2001 From: Jon Simons <jon> Date: Sat, 18 Oct 2014 23:23:26 -0700 Subject: [PATCH] kex: fixup error path in sshpacketkexinit

Before this change, dangling pointers can be unintentionally left in the respective nextcrypto kex methods slots. Ensure to set all slots to NULL in the error-out path.

Signed-off-by: Jon Simons <jon> --- src/kex.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/src/kex.c b/src/kex.c index f1a1b56..ee00ec3 100644 --- a/src/kex.c +++ b/src/kex.c @@ -443,6 +443,11 @@ SSHPACKETCALLBACK(sshpacketkexinit){ error: sshstringfree(str); for (i = 0; i < SSHKEXMETHODS; i++) { + if (serverkex) { + session->nextcrypto->clientkex.methods[i] = NULL; + } else { / client / + session->nextcrypto->serverkex.methods[i] = NULL; + } SAFEFREE(strings[i]); } -- 1.9.1

A flaw was found in libssh server. When accepting a new connection, the server forks and the child process handles the request. The RANDbytes() function of openssl doesn't reset its state after the fork, but simply adds the current process id (getpid) to the PRNG state, which is not guaranteed to be unique. The most important consequence is that servers using EC (ECDSA) or DSA certificates may under certain conditions leak their private key.

The publickeyfromprivatekey function in libssh before 0.5.4, when no algorithm is matched during negotiations, allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a "Client: Diffie-Hellman Key Exchange Init" packet.

Double free vulnerability in the sftpmkdir function in sftp.c in libssh before 0.5.3 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via unspecified vectors, a different vector than CVE-2012-4559.

Florian Weimer of the Red Hat Product Security Team reported many instances of overflow checks in libssh's buffer.c that were incorrect:

if ((buffer->pos + hostlen) > buffer->used) {

This should probably be:

if (hostlen > buffer->used - buffer->pos) {

It seems this could be used to trigger a large memory allocation which is immediately freed, so this is mostly harmless (not exploitable for code execution or denial of service).

A similar problem occurs in bufferadddata():

if (buffer->allocated < (buffer->used + len)) {

len should stand on its own.

Likewise in bufferprependdata():

if (buffer->allocated < (buffer->used - buffer->pos + len)) {

And bufferpassbytes(), bufferpassbytesend(), buffergetmpint():

if(buffer->used < buffer->pos+len)

if(buffer->used < buffer->pos + len)

if ((buffer->pos + len) > buffer->used) {

While it is not certain that any of these are actually be exploitable, the checks are incorrect and need to be fixed.

Florian Weimer of the Red Hat Product Security Team reported the existence of several unitialized heap allocations in the following functions:

keys.c:publickeymakedss() (key) keys.c:publickeymakersa() (key) keys.c:signaturefromstring() (sign) keys.c:sshdosign() (sign) keys.c:sshsignsessionid() (sign)

This could lead to freeing an invalid pointer on an error path, which could lead to a crash in the process using libssh.

Florian Weimer of the Red Hat Product Security Team reported two cases where a function in libssh would write one past the end of the buffer (the u buffer in misc.c:sshpathexpandtilde() and the buf buffer in misc.c:sshpathexpandescape()).

Florian Weimer of the Red Hat Product Security Team reported several instances of code in libssh where a heap region is deallocated twice, first in the main path and then on the error path. This could crash the process using libssh, or possible allow for the execution of arbitrary code.

The identified affected variables are:

agent.c:agentsigndata(): request channels.c:channelrequest(): req auth.c:sshuserauthpubkey(): user, service, method, algo, pkstr sftp.c:sftpparseattr3(): longname, name sftp.c:sftpmkdir(): buffer, path keyfiles.c:trypublickeyfromfile(): pubkey

sftp.c:sftpmkdir() has been corrected via the following git commit:

http://git.libssh.org/projects/libssh.git/commit/?h=v0-5&id=4d8420f3282ed07fc99fc5e930c17df27ef1e9b2