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 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

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.

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.

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