Follow-up to 4e04ec8, which caused a regression on OS X.
Checking the value of CMAKE_THREAD_LIBS_INIT to decide whether any threading
library is present on a system turns out to be wrong -- in OS X, for
example, usage of pthreads does not depend on any additional linker or
compiler flags, so CMAKE_THREAD_LIBS_INIT is empty and our check in
src/CMakeLists.txt failed (it used to work before 4e04ec8 because
CMAKE_HAVE_THREADS_LIBRARY is set).
Instead, just look for Threads_FOUND, which FindThreads sets just like any
other Find module when it has found what it was looking for.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Fix bug #142
The mode does need to be an octal numeric string. Mode 0600 now gets sent on the wire as 0384, triggering a "scp: protocol error: bad mode" response, and an "scp status code 1d not valid" message from libssh.
Goal of that function is to test the preferred key exchange methods
based on what's available in the known_hosts file
Conflicts:
tests/client/torture_knownhosts.c
As mentioned in the previous commit, there are cases where
CMAKE_HAVE_THREADS_LIBRARY is not set and pthreads _is_ being used: one can
pass -DTHREADS_HAVE_PTHREAD_ARG=1 to CMake directly so that it just passes
-pthread to the compiler/linker and does not set CMAKE_HAVE_THREADS_LIBRARY.
Since we are only interested in knowing whether any threading library has
been found, we should use CMAKE_THREAD_LIBS_INIT instead (Threads_FOUND
would also work).
Note that, at the moment, there is only a pthreads backend available in
threads/, so if it is not found configuration will fail because CMake will
try to create a library from an empty set of source files.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to check whether the socket at hand is indeed still connected
throughout POLLIN processing in ssh_socket_pollcallback.
Before this change, the POLLIN block in ssh_socket_pollcallback is
predicated against the condition (s->state == SSH_SOCKET_CONNECTED).
Once entered, data from the socket is consumed through the data
callback in this loop:
do {
r = s->callbacks->data(buffer_get_rest(s->in_buffer),
buffer_get_rest_len(s->in_buffer),
s->callbacks->userdata);
buffer_pass_bytes(s->in_buffer,r);
} while (r > 0);
However, it is possible for the socket data callback to change the
state of the socket (closing it, for example). Fix the loop to only
continue so long as the socket remains connected: this also entails
setting the ssh_socket state to SSH_SOCKET_CLOSED upon close.
The bug can be observed before the change by sending a bogus banner
to the server: 'echo -e "A\r\nB\r\n" | nc localhost 22'. Each of
'A' and 'B' will be processed by 'callback_receive_banner', even
though the client socket is closed after rejection of 'A'.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
So that it would match ssh_channel_pty_request_callback as well as the documentation
Signed-off-by: Audrius Butkevicius <audrius.butkevicius@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
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.
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>
