The final main loop in do_ssh2_authconn will sometimes loop over all
currently open channels calling ssh2_try_send_and_unthrottle. If the
channel is a sharing one, however, that will reference fields of the
channel structure like 'remwindow', which were never initialised in
the first place (thanks, valgrind). Fix by excluding CHAN_SHARING
channels from that loop.
(cherry picked from commit 7366fde1d4)
If the real SSH connection goes away and we call sharestate_free with
downstreams still active, then that in turn calls share_connstate_free
on all those downstreams, freeing the things their sockets are using
as Plugs but not actually closing the sockets, so further data coming
in from downstream gives rise to a use-after-free bug.
(Thanks to Timothe Litt for a great deal of help debugging this.)
(cherry picked from commit 0b2f283622)
This allows files other than sshbn.c to work with the primitives
necessary to build multi-word arithmetic functions satisfying all of
PuTTY's portability constraints.
(cherry picked from commit 2c60070aad)
Cherry-picker's notes: required on this branch because it's a
dependency of f8b27925ee which we want.
Installing this systemwide as the Windows text selection cursor is a
workaround for 'black-pointer'. It's a white I-beam with a one-pixel
black outline around it, so it should be visible on any background
colour. (I suppose that a backdrop of tightly packed I-beams looking
just like it might successfully hide it, but that's unlikely :-)
I constructed this some years ago for personal use; I needed it again
this week and had to go and recover it from a backup of a defunct
system, which made me think I really ought to check it in somewhere,
and this 'contrib' directory seems like the ideal place.
(cherry picked from commit e222db14ff)
An unguarded write() in the dputs function caused gcc -Werror to fail
to compile. I'm confused that this hasn't bitten me before, though -
obviously normal builds of PuTTY condition out the faulty code, but
_surely_ this can't be the first time I've enabled the developer
diagnostics since gcc started complaining about unchecked syscall
returns!
(cherry picked from commit 35fde00fd1)
When anyone connects to a PuTTY tool's listening socket - whether it's
a user of a local->remote port forwarding, a connection-sharing
downstream or a client of Pageant - we'd like to log as much
information as we can find out about where the connection came from.
To that end, I've implemented a function sk_peer_info() in the socket
abstraction, which returns a freeform text string as best it can (or
NULL, if it can't get anything at all) describing the thing at the
other end of the connection. For TCP connections, this is done using
getpeername() to get an IP address and port in the obvious way; for
Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some
moderately hairy autoconfery) to get the pid and owner of the peer. I
haven't implemented anything for Windows named pipes, but I will if I
hear of anything useful.
(cherry picked from commit c8f83979a3)
Conflicts:
pageant.c
Cherry-picker's notes: the conflict was because the original commit
also added a use of the same feature in the centralised Pageant code,
which doesn't exist on this branch. Also I had to remove 'const' from
the type of the second parameter to wrap_send_port_open(), since this
branch hasn't had the same extensive const-fixing as master.
The last use of it, to store the contents of the saved session name
edit box, was removed nearly two years ago in svn r9923 and replaced
by ctrl_alloc_with_free. The mechanism has been unused ever since
then, and I suspect any further uses of it would be a bad idea for the
same reasons, so let's get rid of it.
(cherry picked from commit 42c592c4ef)
The memory dangling off ssd->sesslist should be freed when ssd itself
goes away, and the font settings ctrlset we delete in gtkcfg.c should
be freed as well once it's been removed from its containing array.
Thanks to Ranjini Aravind for pointing these out.
(cherry picked from commit f4956a1f9d)
Since I've recently published a program that can easily generate the
required digits of pi, and since I was messing around in sshblowf.c
already, it seemed like a good idea to provide a derivation of all
that hex data.
(cherry picked from commit 2968563180)
SSH2_MSG_KEX_DH_GEX_REQUEST_OLD and SSH2_MSG_KEX_DH_GEX_REQUEST were
correctly _defined_ as different numbers, but the comments to the
right containing the hex representations of their values were
accidentally the same.
(cherry picked from commit a8658edb17)
(cherry picked from commit 16c46ecdaf)
Conflicts:
sshsh512.c
Cherry-picker's notes: the conflict was because the original commit
also added smemclrs to SHA384_Simple and the ssh_hash structures for
SHA-384 and SHA-512, none of which exists on this branch so those
changes are irrelevant.
Now that we have modes in which the MAC verification happens before
any other crypto operation and hence will be the only thing seen by an
attacker, it seems like about time we got round to doing it in a
cautious way that tries to prevent the attacker from using our memcmp
as a timing oracle.
So, here's an smemeq() function which has the semantics of !memcmp but
attempts to run in time dependent only on the length parameter. All
the MAC implementations now use this in place of !memcmp to verify the
MAC on input data.
(cherry picked from commit 9d5a164021)
Cherry-picker's notes: the above commit comment isn't really true on
this branch, since the ETM packet protocol changes haven't been
cherry-picked. But it seemed silly to deliberately leave out even a
small safety measure.
PuTTY now uses the updated version of Diffie-Hellman group exchange,
except for a few old OpenSSH versions which Darren Tucker reports only
support the old version.
FIXME: this needs further work because the Bugs config panel has now
overflowed.
(cherry picked from commit 62a1bce7cb)
When a winhandl.c input thread returns EOF to the main thread, the
latter might immediately delete the input thread's context. I
carefully wrote in a comment that in that case we had to not touch ctx
ever again after signalling to the main thread - but the test for
whether that was true, which also touched ctx, itself came _after_ the
SetEvent which sent that signal. Ahem.
Spotted by Minefield, which it looks as if I haven't run for a while.
(cherry picked from commit 9fec2e7738)
I had set up an event object for signalling incoming connections to
the named pipe, and then called handle_add_foreign_event to get that
event object watched for connections - but when I closed down the
listening pipe, I deleted the event object without also cancelling
that foreign-event handle, so that winhandl.c would potentially call
the callback for a destroyed object.
(cherry picked from commit 6f241cef2c)
A minus sign is illegal at that position in a control sequence, so if
ESC[13t should report something like ESC[3;-123;234t then we won't
accept it as input. Switch to printing the numbers as unsigned, so
that negative window coordinates are output as their 32-bit two's
complement; experimentation suggests that PuTTY does accept that on
input.
(cherry picked from commit 2422b18a0f)
This was an old bug, fixed around 0.59, which apparently regressed
when I rewrote the main event loop using the toplevel_callback
mechanism.
Investigation just now suggests that it has to do with my faulty
assumption that Windows PeekMessage would deliver messages in its
message queue in FIFO order (i.e. that the thing calling itself a
message queue is actually a _queue_). In fact my WM_NETEVENT seems to
like to jump the queue, so that once a steady stream of them starts
arriving, we never do anything else in the main event loop (except
deal with handles).
Worked around in a simple and slightly bodgy way, namely, we don't
stop looping on PeekMessage and run our toplevel callbacks until we've
either run out of messages completely or else seen at least one that
_isn't_ a WM_NETEVENT. That way we should reliably interleave NETEVENT
processing with processing of other stuff.
(cherry picked from commit 7d97c2a8fd)
Mostly I'm rearranging things because of the new workflows that git
makes available - it's now possible (and indeed sensible) to prepare a
lot of stuff in a fairly relaxed manner in local checkouts, and then
the process of going live with the release has a lot less manual
writing of stuff and a lot more mechanical 'git push' and running of
update scripts.
However, there's one new item that was actually missed off the
previous checklist: turning off nightly pre-release builds after
making the release they were a pre-release of. Ahem.
(cherry picked from commit 8af53d1b69)
encodelib.py is a Python library which implements some handy SSH-2
encoding primitives; samplekex.py uses that to fabricate the start of
an SSH connection, up to the point where key exchange totally fails
its crypto.
The idea is that you adapt samplekex.py to construct initial-kex
sequences with particular properties, in order to test robustness and
security fixes that affect the initial-kex sequence. For example, I
used an adaptation of this to test the Diffie-Hellman range check
that's just gone into 0.64.
(cherry picked from commit 12d5b00d62)
To understand the handle leak bug that I fixed in git commit
7549f2da40, I had to think fairly hard
to remind myself what all this code was doing, which means the
comments weren't good enough. Expanded and rewritten some of them in
the hope that things will be clearer next time.
(cherry picked from commit a87a14ae0f)
Cherry-picker's notes: this apparently pointless commit is required on
this branch because it's a dependency of the rather less pointless
9fec2e7738.
The absence of these could have prevented sensitive private key
information from being properly cleared out of memory that PuTTY tools
had finished with.
Thanks to Patrick Coleman for spotting this and sending a patch.
We incremented buf by a few bytes, so we must decrement the
corresponding length by the same amount, or else makekey() could
overrun.
Thanks to Patrick Coleman for the patch.
Florent Daigniere of Matta points out that RFC 4253 actually
_requires_ us to refuse to accept out-of-range values, though it isn't
completely clear to me why this should be a MUST on the receiving end.
Matta considers this to be a security vulnerability, on the grounds
that if a server should accidentally send an obviously useless value
such as 1 then we will fail to reject it and agree a key that an
eavesdropper could also figure out. Their id for this vulnerability is
MATTA-2015-002.
Bare string exceptions aren't supported any more.
Patch by Will Aoki, plus a backward compatibility tweak from Colin Watson.
Seen working with Python 2.4.3 and 2.7.6.
If (say) a read handle returns EOF, and its gotdata function responds
by calling handle_free(), then we want the handle to have already had
its defunct flag set so that the handle can be destroyed. Otherwise
handle_free will set the 'done' flag to ask the subthread to
terminate, and then sit and wait for it to say it's done so -
forgetting that it signalled termination already by returning EOF, and
hence will not be responding to that signal.
Ditto for write errors on write handles, though that should happen
less often.
The code for cleaning up handle structures works by the main thread
asking the per-handle subthread to shut down by means of setting its
'done' flag, and then once the subthread signals back through its
event object that it's done so, the main thread frees all its
resources and removes the event object from the list of things being
checked in the program's event loop.
But read threads were not sending back that final event acknowledging
a request to shut down, so their event objects were never being
cleaned up.
Bug spotted by Ronald Weiss.
It would be rare to have a host keypair in .ppk format or on a client
machine to load into PuTTYgen, and it might confuse people into thinking
they are required to do so.
It tries to use the local username as the remote username if it has no
better ideas, but the presence of Default Settings would defeat this,
even if it had no username set. Reported by Jonathan Amery.
We were checking the return value of CreateThread for validity, but
not keeping it to free afterwards if it _was_ valid. Also, we weren't
closing ctx->event in the valid case either. Patch due to Tim Kosse.
If we use getaddrinfo to translate the source IP address into a
sockaddr, then we need to freeaddrinfo the returned data later. Patch
due to Tim Kosse.
I don't think anyone has ever actually called it that, colloquially
_or_ formally, and if anyone ever did (in a bug report, say) I'd
probably have to stop and think to work out what they meant. It's
universally called Plink, and should be officially so as well :-)
This one spotted in the old-fashioned way, by actually attempting a
Plink raw connection and wondering why it didn't seem to be reading
from standard input! Turns out 'bufsize' is uninitialised until the
first send, which can inhibit any stdin reading if it gets a large
enough nonsense value.
mkfiles.pl was giving a couple of annoying perl warnings, because some
makefile_extra strings were never set by Recipe. We already have the
&def function to convert undefs into "" for this reason, but weren't
using it everywhere. Now I think we are.
If a sharing downstream asks for an auth method we don't understand,
we should send them CHANNEL_FAILURE *and then stop processing*. Ahem.
(Spotted while examining this code in the course of Coverity-related
fixes, but not itself a Coverity-found problem.)
If (Msg)WaitForMultipleObjects returns WAIT_TIMEOUT, we expect 'next'
to have been initialised. This can occur without having called
run_timers(), if a toplevel callback was pending, so we can't expect
run_timers to have reliably initialised 'next'.
I'm not actually convinced this could have come up in either of the
affected programs (Windows PSFTP and Plink), due to the list of things
toplevel callbacks are currently used for, but it certainly wants
fixing anyway for the future.
Spotted by Coverity.
Namely, any ldisc that you send actual data through should have a
terminal attached, because the ldisc editing/echoing system is
designed entirely for use with a terminal. The only time you can have
an ldisc with no terminal is when it's only ever used by the backend
to report changes to the front end in edit/echo status, e.g. by Unix
Plink.
Coverity spotted an oddity in ldisc_send which after a while I decided
would never have actually caused a problem, but OTOH I agree that it
was confusing, so now hopefully it's less so.
