Starting up the random number generator is by far the slowest part of
plink's startup, and randomness is bad for fuzzing, so disabling it
should make fuzzing more effective.
This saves the need to fork and exec "cat", which should speed things
up. It also ensures that the network output goes to /dev/null, which
should avoid problems with blocking when writing to a full pipe.
It's not used outside logfopen, and leaving an invalid file pointer
lying around in the log context caused a segfault if the user
cancelled logging.
Bug found by afl-fuzz before it had even started fuzzing.
This is a minimal fix for CVE-2015-5309, and while it's probably
unnecessary now, it seems worth committing for defence in depth and to
give downstreams something reasonably non-intrusive to cherry-pick.
"amax == 0 || a[amax] != 0"
Essentially, when decodepoint_ed() clears the top bit of the key, it
needs to call bn_restore_invariant() in case that left the high-order
word zero.
Bug found with the help of afl-fuzz.
This one might be exploitable, since without the fix, ecdsa_freekey()
tries to wipe the bignum pointed to by an uninitialised pointer.
Bug found with the help of afl-fuzz.
Parameters are now accumulated in unsigned integers and carefully checked
for overflow (which is turned into saturation). Things that consume them
now have explicit range checks (again, saturating) to ensure that their
inputs are sane. This should make it much harder to cause overflow by
supplying ludicrously large numbers.
Fixes two bugs found with the help of afl-fuzz. One of them may be
exploitable and is CVE-2015-5309.
This is a minimal fix for CVE-2015-5309, and while it's probably
unnecessary now, it seems worth committing for defence in depth and to
give downstreams something reasonably non-intrusive to cherry-pick.
Parameters are now accumulated in unsigned integers and carefully checked
for overflow (which is turned into saturation). Things that consume them
now have explicit range checks (again, saturating) to ensure that their
inputs are sane. This should make it much harder to cause overflow by
supplying ludicrously large numbers.
Fixes two bugs found with the help of afl-fuzz. One of them may be
exploitable and is CVE-2015-5309.
The previous assertion failure is obviously wrong, but RFC 4253 doesn't
explicitly declare them to be a protocol error. Currently, the incoming
packet isn't logged, which might cause some confusion for log parsers.
Bug found with the help of afl-fuzz.
It's not used outside logfopen, and leaving an infalid file pointer
lying around in the log context caused a segfault if the user
cancelled logging.
Bug found by afl-fuzz before it had even started fuzzing.
This protects the Unix platform sharing code in the case where no salt
file exists yet in the connection-sharing directory, in which case
make_dirname() will want to create one by using some random bytes, and
prior to this commit, would fail an assertion because the random
number generator wasn't set up.
It would be neater to just return FALSE from ssh_test_for_upstream in
that situation - if there's no salt file, then no sharing socket can
be valid anyway - but that would involve doing more violence to the
code structure than I'm currently prepared to do for a minor elegance
gain.
On Windows, colons are illegal in filenames, because they're part of
the path syntax. But colons can appear in automatically constructed
log file names, if an IPv6 address is expanded from the &H placeholder.
Now we coerce any such illegal characters to '.', which is a bit of a
bodge but should at least cause a log file to be generated.
(cherry picked from commit 64ec5e03d5)
A user points out that logging fopen failures to the Event Log is a
bit obscure, and it's possible to proceed for months in the assumption
that your sessions are being correctly logged when in fact the
partition was full or you were aiming them at the wrong directory. Now
we produce output visibly in the PuTTY window.
(cherry picked from commit e162810516)
Log files, especially SSH packet logs, are often things you want to
generate in unusual circumstances, so it's good to have lots of ways
to ask for them. Particularly, it's especially painful to have to set
up a custom saved session to get diagnostics out of the command-line
tools.
I've added options '-sessionlog', '-sshlog' and '-sshrawlog', each of
which takes a filename argument. I think the fourth option (session
output but filtered down to the printable subset) is not really a
_debugging_ log in the same sense, so it's not as critical to have an
option for it.
(cherry picked from commit 13edf90e0a)
Plink sets standard input into nonblocking mode, meaning that read()
from fd 0 in an interactive context will typically return -1 EAGAIN.
But the prompt functions in uxcons.c, used for verifying SSH host keys
and suchlike, were doing an unguarded read() from fd 0, and then
panicking and aborting the session when they got EAGAIN.
Fixed by inventing a wrapper around read(2) which handles EAGAIN but
passes all other errors back to the caller. (Seemed slightly less
dangerous than the stateful alternative of temporarily re-blockifying
the file descriptor.)
(cherry picked from commit bea758a7ae)
Conflicts:
unix/uxcons.c
Cherry-picker's notes: the conflict was a trivial one. The new
function block_and_read() by this commit appears just before
verify_ssh_host_key(), which has a new prototype on the source branch,
close enough to disrupt the patch hunk's context. Easily fixed.
The build script generates the .htaccess files that go in each
individual build and redirect generic names like 'putty.tar.gz' to the
real filenames including that build's version number. Those .htaccess
files redirect the corresponding signatures as well, so they need
updating now that we're generating signature files with a different
extension.
(cherry picked from commit 6744387924)
What should have been links to the old DSA keys were actually a second
copy of the links to the old RSA ones. Ahem.
(cherry picked from commit b62af0f40a)
For the moment we're also retaining the old ones. Not sure when will
be the best time to get rid of those; after the next release, perhaps?
(cherry picked from commit e88b8d21f2)
sign.sh's command-line syntax has changed, so I've updated the sample
command line in CHECKLST as well. Also the file extensions of the
signatures have changed, so I've updated the pre-release verification
command line in CHECKLST too.
(cherry picked from commit 11eb75a260)
This gives pride of place to the new set of keys we've recently
generated, and relegates the old ones to an afterthought.
(cherry picked from commit bb68baf53b)
In a UTF-8 pterm, it makes sense to set the IUTF8 flag (on systems
that have one) on the pty device, so that line editing will take
account of UTF-8 multibyte characters.
(cherry picked from commit 1840103c05)
Profiling reveals that pterm in Pango rendering mode uses an absurd
amount of CPU when it's not even actually _drawing_ the text, because
of all the calls to pango_layout_get_pixel_extents() while
pangofont_draw_text tries to work out which characters it can safely
draw as part of a long string. Caching the results speeds things up
greatly.
(cherry picked from commit c3ef30c883)
If you open a pterm on a different display via the --display
command-line option rather than by setting $DISPLAY, I think (and
other terminals seem to agree) that it's sensible to set $DISPLAY
anyway for processes running inside the terminal.
(cherry picked from commit dc16dd5aa4)
Users have requested this from time to time, for distinguishing log
file names when there's more than one SSH server running on different
ports of the same host. Since we do take account of that possibility
in other areas (e.g. we cache host keys indexed by (host,port) rather
than just host), it doesn't seem unreasonable to do so here too.
(cherry picked from commit 0550943b51)
We've had several reports that launching saved sessions from the
Windows 10 jump list fails; Changyu Li reports that this is because we
create those IShellLink objects with a command line string starting
with @, and in Windows 10 that causes the SetArguments method to
silently do the wrong thing.
(cherry picked from commit 8bf5c1b31f)
A user reports that in a particular situation one of the calls to
LoadLibrary from wingss.c has unwanted side effects, and points out
that this happens even when the saved session has GSSAPI disabled. So
I've evaluated as much as possible of the condition under which we
check the results of GSS library loading, and deferred the library
loading itself until after that condition says we even care about the
results.
(cherry picked from commit 9a08d9a7c1)
This is generated in response to the SendInput() Windows API call, if
that in turn is passed an KEYBDINPUT structure with KEYEVENTF_UNICODE
set. That method of input generation is used by programs such as
'WinCompose' to send an arbitrary Unicode character as if it had been
typed at the keyboard, even if the keyboard doesn't actually provide a
key for it.
Like VK_PROCESSKEY, this key code is an exception to our usual policy
of manually translating keystrokes: we handle it by calling
TranslateMessage, to get back the Unicode character it contains as a
WM_CHAR message.
(If that Unicode character in turn is outside the BMP, it may come
back as a pair of WM_CHARs in succession containing UTF-16 surrogates;
if so, that's OK, because the new Unicode WM_CHAR handler can cope.)
(cherry picked from commit 65f3500906)
This causes WM_CHAR messages sent to us to have a wParam containing a
16-bit value encoded in UTF-16, rather than an 8-bit value encoded in
the system code page.
As far as I can tell, there aren't many other knock-on effects - e.g.
you can still interact with the window using ordinary char-based API
functions such as SetWindowText, and the Windows API will do the
necessary conversions behind the scenes. However, even so, I'm half
expecting some sort of unforeseen bug to show up as a result of this.
(cherry picked from commit 67e5ceb9a8)
PuTTY's main mb_to_wc() function is all very well for embedding in
fiddly data pipelines, but for the simple job of turning a C string
into a C wide string, really I want something much more like
dupprintf. So here is one.
I've had to put it in a new separate source file miscucs.c rather than
throwing it into misc.c, because misc.c is linked into tools that
don't also include a module providing the internal Unicode API (winucs
or uxucs). The new miscucs.c appears only in Unicode-using tools.
(cherry picked from commit 7762d71226)
The -F option is no longer needed to bob in this situation; that
hasn't been the directory I keep release announcements in for a long
time; the Docs page needs adjusting for pre-release retirement as well
as the Downloads page.
(cherry picked from commit 9bea08a298)
I broke it as a side effect of commit 30e63c105, in which I intended
to ignore mouse drag events that hadn't been preceded by a click. I
didn't spot that right-clicks (assuming Unix-style button mappings) go
through the same code path as left-drags, and hence were being ignored
even though they _were_ their own initiating click.
Ben Harris
Simon Tatham
Jacob Nevins
Tim Kosse