Fix the DSA portion of 'pki_signature_to_blob': before this change, it
is possible to sometimes observe DSA signature validation failure when
testing with OpenSSH clients. The problem ended up being the following
snippet which did not account for the case when 'ssh_string_len(x)' may
be less than 20:
r = make_bignum_string(sig->dsa_sig->r);
...
memcpy(buffer,
((char *) ssh_string_data(r)) + ssh_string_len(r) - 20,
20);
Above consider the case that ssh_string_len(r) is 19; in that case the
memcpy unintentionally starts in the wrong place. The same situation
can happen for value 's' in this code.
To fix, adjust the offsets used for the input and output pointers, taking
into account that the lengths of 'r' and 's' can be less than 20. With
the fix I am no longer able to reproduce the original failure mode.
BUG: https://red.libssh.org/issues/144
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
ssh_get_error can actually work on anything with an ssh_common_struct
as its first member. It is already used in examples in the
distribution with ssh_sessions and ssh_binds.
Signed-off-by: Alan Dunn <amdunn@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Pad RSA signature blobs to the expected RSA signature length
when processing via 'pki_signature_to_blob'.
Some clients, notably PuTTY, may send unpadded RSA signatures
during the public key exchange: before this change, one can
sometimes observe failure in signature validation when using
PuTTY's 'plink' client, along these lines:
ssh_packet_process: ssh_packet_process: Dispatching handler for packet type 50
ssh_packet_userauth_request: ssh_packet_userauth_request: Auth request for service ssh-connection, method publickey for user 'foo'
ssh_pki_signature_verify_blob: ssh_pki_signature_verify_blob: Going to verify a ssh-rsa type signature
pki_signature_verify: pki_signature_verify: RSA error: error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length
ssh_packet_userauth_request: ssh_packet_userauth_request: Received an invalid signature from peer
For cross-reference this issue once also existed between
PuTTY and OpenSSH:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed.htmlhttp://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c?rev=1.19;content-type=text%2Fx-cvsweb-markup
With the fix I am unable to reproduce the above failure mode when
testing with 'plink'.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Make sure to explicitly set key pointers to NULL following the use
of 'ssh_key_free' throughout bind.c.
Before this change, a double free can happen via 'ssh_bind_free'
as in this example callpath:
// create an ssh_bind
ssh_bind b = ssh_bind_new();
// provide a path to a wrong key-type
ssh_bind_options_set(b, SSH_BIND_OPTIONS_DSAKEY, path_to_rsa_key);
// initialize set key-type
ssh_bind_listen(b);
-> error path "The DSA host key has the wrong type: %d",
ssh_key_free(sshbind->dsa)
-> ssh_key_clean(key) // OK
-> SAFE_FREE(key) // OK, but, sshbind->dsa is *not* set to NULL
// ssh_bind_listen failed, so clean up ssh_bind
ssh_bind_free(b);
-> ssh_key_free(sshbind->dsa) // double-free here
To fix, set pointers to NULL that have been free'd with 'ssh_key_free'.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This works same way as ssh_forward_accept() but can return a destination
port of the channel (useful if SSH connection forwarding several TCP/IP
ports).
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Not 100% satisfied of this patch, but the way libgcrypt handles
threading in 1.6 is not compatible with custom handlers. The
new code basicaly uses pthreads in every case. This will probably
not work on windows.
The ssh_userauth_none() call should already be non-blocking. However
this this function is broken in non-blocking mode. It should reveal the
existing bug.
Fix the setting of 'channel->flags' to use '|='. Before this
change, one bug symptom can be that channels are never fully
free'd via ssh_channel_free, resulting in memory leaks.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to use 'ssh_channel_do_free' in 'ssh_disconnect', when removing and
free'ing up a session's channels. This matches the behavior in 'ssh_free',
and is necessary to fully free any channel which may not have been closed
completely (see usage of flags SSH_CHANNEL_FLAG_CLOSED_REMOTE,
SSH_CHANNEL_FLAG_FREED_LOCAL).
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
