lp:~vcs-imports/putty/master

Created by Colin Watson on 2016-10-02 and last modified on 2019-02-13
Get this branch:
bzr branch lp:~vcs-imports/putty/master

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
PuTTY
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.tartarus.org/simon/putty.git.

The next import is scheduled to run in 4 hours.

Last successful import was 1 hour ago.

Import started 1 hour ago on alnitak and finished 1 hour ago taking 20 seconds — see the log
Import started 7 hours ago on izar and finished 7 hours ago taking 20 seconds — see the log
Import started 13 hours ago on alnitak and finished 13 hours ago taking 20 seconds — see the log
Import started 19 hours ago on izar and finished 19 hours ago taking 15 seconds — see the log
Import started on 2019-02-15 on izar and finished on 2019-02-15 taking 20 seconds — see the log
Import started on 2019-02-14 on izar and finished on 2019-02-14 taking 15 seconds — see the log
Import started on 2019-02-14 on alnitak and finished on 2019-02-14 taking 20 seconds — see the log
Import started on 2019-02-14 on alnitak and finished on 2019-02-14 taking 15 seconds — see the log
Import started on 2019-02-14 on alnitak and finished on 2019-02-14 taking 20 seconds — see the log
Import started on 2019-02-13 on alnitak and finished on 2019-02-13 taking 20 seconds — see the log

Recent revisions

5256. By Simon Tatham <email address hidden> on 2019-02-13

uxpty.c: initialise pty->pending_eof.

valgrind just pointed out that it wasn't.

5255. By Simon Tatham <email address hidden> on 2019-02-11

Fix crash on entering wrong passphrase.

When I added the new call to ssh_key_invalid the other day, I forgot
to avoid calling it if the key is NULL (and therefore even more
obviously invalid).

5254. By Simon Tatham <email address hidden> on 2019-02-10

Add missing sanity checks in ssh_dss_verify.

The standard says we should be checking that both r,s are in the range
[1,q-1]. Previously we were effectively reducing s mod q in the course
of inversion, and modinv() was guaranteeing never to return zero; the
remaining missing checks were benign. But the change from Bignum to
mp_int altered the error behaviour, and combined with the missing
upper bound check on s, made it possible to continue verification with
w == 0 mod q, which is a bad case.

Added a small DSA test case, including a check that none of these
types of signatures validates.

5253. By Simon Tatham <email address hidden> on 2019-02-10

Windows PuTTYgen: bound entropy input by PRNG state size.

Although I've reinstated the tedious manual mouse input, I can at
least reduce the amount of it that the user is required to provide:
the new PRNG has a hard limit on the size of its seed, so once we've
generated enough entropy to fill that up, there's no point in
collecting more, even if we're generating a particularly large key.

5252. By Simon Tatham <email address hidden> on 2019-02-10

Windows PuTTYgen: reinstate mouse-based entropy collection.

This reverts the policy change in 6142013ab (though not the detailed
code changes - I've kept the reorganised code layout). Now the old
mouse-based manual entropy collection is once again required when
generating a public key.

Rationale: I came across Wikipedia's page on CryptGenRandom which
mentioned that it was not a true kernel-level PRNG of the /dev/random
variety, but rather a thing running in userland, no different in
principle from PuTTY's own. So I think that makes it no longer a thing
we should rely on for all our entropy, and I'm relegating it back to
being just one entropy source among many.

5251. By Simon Tatham <email address hidden> on 2019-02-10

mp_cond_swap: add a brute-force 'volatile'.

With this change, my new side-channel test system gets a 100% pass
rate when compiled with clang -O3 on Ubuntu 18.10. Previously, it had
three failing tests (namely the three ECC multiply functions), all due
to inconsistent control flow inside mp_cond_swap.

I admit I don't really understand whether this is really necessary or
not, so I'm playing it safe. The problem _seems_ to be that clang has
generated one version of the cond_swap loop using integer arithmetic
and another using MMX vectors, so the obvious suspect is alignment -
probably mp_cond_swap is processing an iteration of the loop up front
until its pointer is 16-byte aligned and then switching over to the
vectorised version. But on the other hand, when I experimentally tried
forcing allocations to be 16- or even 32-byte aligned, it didn't make
a difference. And I don't speak x86 vector instructions very well (in
fact barely at all), so I'm not even completely sure of whether the
code I was reading did what I thought it did; so I'm more comfortable
with simply applying brute force to get some code generation that the
automated test is genuinely happy with.

5250. By Simon Tatham <email address hidden> on 2019-02-10

New test system to detect side channels in crypto code.

All the work I've put in in the last few months to eliminate timing
and cache side channels from PuTTY's mp_int and cipher implementations
has been on a seat-of-the-pants basis: just thinking very hard about
what kinds of language construction I think would be safe to use, and
trying not to absentmindedly leave a conditional branch or a cast to
bool somewhere vital.

Now I've got a test suite! The basic idea is that you run the same
crypto primitive multiple times, with inputs differing only in ways
that are supposed to avoid being leaked by timing or leaving evidence
in the cache; then you instrument the code so that it logs all the
control flow, memory access and a couple of other relevant things in
each of those runs, and finally, compare the logs and expect them to
be identical.

The instrumentation is done using DynamoRIO, which I found to be well
suited to this kind of work: it lets you define custom modifications
of the code in a reasonably low-effort way, and it lets you work at
both the low level of examining single instructions _and_ the higher
level of the function call ABI (so you can give things like malloc
special treatment, not to mention intercepting communications from the
program being instrumented). Build instructions are all in the comment
at the top of testsc.c.

At present, I've found this test to give a 100% pass rate using gcc
-O0 and -O3 (Ubuntu 18.10). With clang, there are a couple of
failures, which I'll fix in the next commit.

5249. By Simon Tatham <email address hidden> on 2019-02-10

Stop falling back to 16-bit BignumInt on VS Arm builds.

The case previously conditioned on _M_IX86, where we use __int64 as
the BignumDblInt type, is actually valid on any Visual Studio target
platform at all, so it's safe to remove that condition and let it
apply to _M_ARM and _M_ARM64 as well. The only situation in which we
_shouldn't_ use that case for Visual Studio builds is when we have
something even better available, such as the x86-64 intrinsics for
add-with-carry and double-width multiply.

5248. By Simon Tatham <email address hidden> on 2019-02-10

Stop aborting the connection if Pageant won't sign.

There's been a FIXME comment in there for ages saying we should do
something less drastic than ssh_sw_abort(). This actually came up in
the course of testing Pageant's support for the new RSA validity
check, so I've fixed it: if Pageant won't deliver us a signature from
the private key we'd like, then we treat it the same as any other auth
method failure: shrug and move on to the next method on our list (or
even just the next key in Pageant).

5247. By Simon Tatham <email address hidden> on 2019-02-10

Give a sensible error when using a too-short RSA key.

The ssh_signkey vtable has grown a new method ssh_key_invalid(), which
checks whether the key is going to be usable for constructing a
signature at all. Currently the only way this can fail is if it's an
RSA key so short that there isn't room to put all the PKCS#1
formatting in the signature preimage integer, but the return value is
an arbitrary error message just in case more reasons are needed later.

This is tested separately rather than at key-creation time because of
the signature flags system: an RSA key of intermediate length could be
valid for SHA-1 signing but not for SHA-512. So really this method
should be called at the point where you've decided what sig flags you
want to use, and you're checking if _those flags_ are OK.

On the verification side, there's no need for a separate check. If
someone presents us with an RSA key so short that it's impossible to
encode a valid signature using it, then we simply regard all
signatures as invalid.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers