From bf98289914f47f394aa0cc442c267e56490c9e70 Mon Sep 17 00:00:00 2001 From: jacob Date: Sun, 22 Oct 2006 19:51:28 +0000 Subject: [PATCH] Minor semantic tweak to bug-compatibility modes: make BUG_NEEDS_SSH1_PLAIN_PASSWORD do exactly what it says on the tin, independent of whether BUG_CHOKES_ON_SSH1_IGNORE is set. This is invisible in the default configuration, as all servers marked as having the second bug have the first one too, but it would allow one to manually configure PuTTY to cope with a SSH-1 server that got upset by ignore messages during authentication, but was fine with their use as keepalives. git-svn-id: svn://svn.tartarus.org/sgt/putty@6876 cda61777-01e9-0310-a592-d414129be87e --- doc/config.but | 16 +++++++++------- ssh.c | 33 +++++++++++++++++++-------------- 2 files changed, 28 insertions(+), 21 deletions(-) diff --git a/doc/config.but b/doc/config.but index ff418917..18c9d9fb 100644 --- a/doc/config.but +++ b/doc/config.but @@ -2789,10 +2789,11 @@ to try to guess whether or not the server has the bug. An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the -message whenever it receives it. PuTTY uses ignore messages to hide -the password packet in SSH-1, so that a listener cannot tell the -length of the user's password; it also uses ignore messages for -connection keepalives (see \k{config-keepalive}). +message whenever it receives it. PuTTY uses ignore messages to +\I{password camouflage}hide the password packet in SSH-1, so that +a listener cannot tell the length of the user's password; it also +uses ignore messages for connection \i{keepalives} (see +\k{config-keepalive}). If this bug is detected, PuTTY will stop using ignore messages. This means that keepalives will stop working, and PuTTY will have to fall @@ -2819,9 +2820,10 @@ camouflage. In this sense, for a server to refuse to accept a padded password packet is not really a bug, but it does make life inconvenient if the server can also not handle ignore messages. -If this \q{bug} is detected, PuTTY will have no choice but to send -the user's password with no form of camouflage, so that an -eavesdropping user will be easily able to find out the exact length +If this \q{bug} is detected, PuTTY will assume that neither ignore +messages nor padding are acceptable, and that it thus has no choice +but to send the user's password with no form of camouflage, so that +an eavesdropping user will be easily able to find out the exact length of the password. If this bug is enabled when talking to a correct server, the session will succeed, but will be more vulnerable to eavesdroppers than it could be. diff --git a/ssh.c b/ssh.c index 81474855..fc75e91a 100644 --- a/ssh.c +++ b/ssh.c @@ -2166,6 +2166,13 @@ static void ssh_detect_bugs(Ssh ssh, char *vstring) ssh->remote_bugs = 0; + /* + * General notes on server version strings: + * - Not all servers reporting "Cisco-1.25" have all the bugs listed + * here -- in particular, we've heard of one that's perfectly happy + * with SSH1_MSG_IGNOREs -- but this string never seems to change, + * so we can't distinguish them. + */ if (ssh->cfg.sshbug_ignore1 == FORCE_ON || (ssh->cfg.sshbug_ignore1 == AUTO && (!strcmp(imp, "1.2.18") || !strcmp(imp, "1.2.19") || @@ -3703,19 +3710,19 @@ static int do_ssh1_login(Ssh ssh, unsigned char *in, int inlen, * magnitude of the password length, but it will * introduce a bit of extra uncertainty. * - * A few servers (the old 1.2.18 through 1.2.22) - * can't deal with SSH1_MSG_IGNORE. For these - * servers, we need an alternative defence. We make - * use of the fact that the password is interpreted - * as a C string: so we can append a NUL, then some - * random data. + * A few servers can't deal with SSH1_MSG_IGNORE, at + * least in this context. For these servers, we need + * an alternative defence. We make use of the fact + * that the password is interpreted as a C string: + * so we can append a NUL, then some random data. * - * One server (a Cisco one) can deal with neither - * SSH1_MSG_IGNORE _nor_ a padded password string. - * For this server we are left with no defences + * A few servers can deal with neither SSH1_MSG_IGNORE + * here _nor_ a padded password string. + * For these servers we are left with no defences * against password length sniffing. */ - if (!(ssh->remote_bugs & BUG_CHOKES_ON_SSH1_IGNORE)) { + if (!(ssh->remote_bugs & BUG_CHOKES_ON_SSH1_IGNORE) && + !(ssh->remote_bugs & BUG_NEEDS_SSH1_PLAIN_PASSWORD)) { /* * The server can deal with SSH1_MSG_IGNORE, so * we can use the primary defence. @@ -3784,10 +3791,8 @@ static int do_ssh1_login(Ssh ssh, unsigned char *in, int inlen, PKTT_OTHER, PKT_END); } else { /* - * The server has _both_ - * BUG_CHOKES_ON_SSH1_IGNORE and - * BUG_NEEDS_SSH1_PLAIN_PASSWORD. There is - * therefore nothing we can do. + * The server is believed unable to cope with + * any of our password camouflage methods. */ int len; len = strlen(s->cur_prompt->prompts[0]->result); -- 2.11.0