simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  5f5c710c New option to reject 'trivial' success of userauth.
  ff941299 Uppity: add stunt options for trivial authentication.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2021-06-20 16:10:44

commit 5f5c710cf3704737e24ffceb2c918e412a2a674f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5f5c710cf3704737e24ffceb2c918e412a2a674f;hp=6d05e20a0e9f81eaefd157c7fd13b1bb2c96ceed
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jun 19 15:39:15 2021 +0100

    New option to reject 'trivial' success of userauth.
    
    Suggested by Manfred Kaiser, who also wrote most of this patch
    (although outlying parts, like documentation and SSH-1 support, are by
    me).
    
    This is a second line of defence against the kind of spoofing attacks
    in which a malicious or compromised SSH server rushes the client
    through the userauth phase of SSH without actually requiring any auth
    inputs (passwords or signatures or whatever), and then at the start of
    the connection phase it presents something like a spoof prompt,
    intended to be taken for part of userauth by the user but in fact with
    some more sinister purpose.
    
    Our existing line of defence against this is the trust sigil system,
    and as far as I know, that's still working. This option allows a bit of
    extra defence in depth: if you don't expect your SSH server to
    trivially accept authentication in the first place, then enabling this
    option will cause PuTTY to disconnect if it unexpectedly does so,
    without the user having to spot the presence or absence of a fiddly
    little sigil anywhere.
    
    Several types of authentication count as 'trivial'. The obvious one is
    the SSH-2 "none" method, which clients always try first so that the
    failure message will tell them what else they can try, and which a
    server can instead accept in order to authenticate you unconditionally.
    But there are two other ways to do it that we know of: one is to run
    keyboard-interactive authentication and send an empty INFO_REQUEST
    packet containing no actual prompts for the user, and another even
    weirder one is to send USERAUTH_SUCCESS in response to the user's
    preliminary *offer* of a public key (instead of sending the usual PK_OK
    to request an actual signature from the key).
    
    This new option detects all of those, by clearing the 'is_trivial_auth'
    flag only when we send some kind of substantive authentication response
    (be it a password, a k-i prompt response, a signature, or a GSSAPI
    token). So even if there's a further path through the userauth maze we
    haven't spotted, that somehow avoids sending anything substantive, this
    strategy should still pick it up.

 cmdline.c              |  8 ++++++++
 config.c               |  4 ++++
 doc/config.but         | 43 +++++++++++++++++++++++++++++++++++++++++++
 pscp.c                 |  2 ++
 psftp.c                |  2 ++
 putty.h                |  1 +
 settings.c             |  2 ++
 ssh/login1.c           | 14 +++++++++++++-
 ssh/ppl.h              |  2 +-
 ssh/ssh.c              |  4 +++-
 ssh/userauth2-client.c | 20 ++++++++++++++++----
 unix/plink.c           |  2 ++
 windows/help.h         |  1 +
 windows/plink.c        |  2 ++
 14 files changed, 100 insertions(+), 7 deletions(-)

commit ff941299cfc427f8ba2939d1950d8f954e3e3602
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ff941299cfc427f8ba2939d1950d8f954e3e3602;hp=5f5c710cf3704737e24ffceb2c918e412a2a674f
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jun 19 15:41:18 2021 +0100

    Uppity: add stunt options for trivial authentication.
    
    This allows the 'no trivial auth' option introduced by the previous
    commit to be tested. Uppity has grown three new options to make it
    accept "none" authentication, keyboard-interactive involving no
    prompts, and the perverse sending of USERAUTH_SUCCESS after a
    signatureless public-key offer.
    
    The first of those options also enables the analogue in SSH-1; the
    other two have no SSH-1 analogues in the first place. (SSH-1 public
    key authentication has a challenge-response structure that doesn't
    contain any way to terminate the exchange early with success. And the
    TIS and CryptoCard methods, which are its closest analogue of k-i,
    have a fixed number of prompts, which is not 0.)

 ssh/login1-server.c    |  5 ++--
 ssh/server.h           |  3 ++
 ssh/userauth2-server.c |  6 ++--
 unix/uppity.c          | 74 +++++++++++++++++++++++++++++++++++---------------
 4 files changed, 62 insertions(+), 26 deletions(-)