openssh unix dev - Jun 2004 - SSH_MSG_USERAUTH_PASSWD_CHANGEREQ and 3.1.0 F-SECURE SSH - Proces s Software SSH for OpenVMS

I have found that this server,

<snip>
debug1: Remote protocol version 1.99, remote software version 3.1.0 F-SECURE
SSH - Process Software SSH for OpenVMS
debug1: no match: 3.1.0 F-SECURE SSH - Process Software SSH for OpenVMS
</snip>

does not follow the IETF secsh draft [1] related to the
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message. 

<snip>
...
   Normally, the server responds to this message with success or
   failure.  However, if the password has expired the server SHOULD
   indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
   In any case the server MUST NOT allow an expired password to be used
   for authentication.
      byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
      string    prompt in ISO-10646 UTF-8 encoding
      string    language tag as defined in [RFC3066]
...
</snip>


I tested with the OpenBSD ssh client and portable ssh in cygwin.

It specifically doesn't send the language tag. Here is the tail of ssh -vvv,

<snip>
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug2: input_userauth_passwd_changereq
buffer_get: trying to get more bytes 4 than in buffer 0
</snip>

I stepped through in the debugger to see that I do get the password change
prompt and then we barf when we try to get the lang string that isn't there.

Here is a patch that gets around this but I had some questions,
1. I wasn't sure I should combine this with the other F-Secure bug listed
(the one for the 1.3.2*)? Is there a regression test to test
SSH_BUG_IGNOREMSG?

2. I wasn't sure how much of the server version string was needed.

3. The selection of SSH_BUG_PWDCHGREQ and it's define was totally arbitrary
by me.


Any feedback greatly appreciated.

cheers,
scott rankin


Index: compat.c
==================================================================RCS file:
/cvs/openssh/compat.c,v
retrieving revision 1.70
diff -d -u -r1.70 compat.c
--- compat.c	3 Nov 2003 09:09:03 -0000	1.70
+++ compat.c	17 Jun 2004 22:02:55 -0000
@@ -134,6 +134,8 @@
 		  "1.2.22*",		SSH_BUG_IGNOREMSG },
 		{ "1.3.2*",		/* F-Secure */
 					SSH_BUG_IGNOREMSG },
+		{ "3.1.0 F-SECURE*",	/* Process Software SSH for OpenVMS
*/
+					SSH_BUG_PWDCHGREQ },
 		{ "*SSH Compatible Server*",			/* Netscreen
*/
 					SSH_BUG_PASSWORDPAD },
 		{ "*OSU_0*,"
Index: compat.h
==================================================================RCS file:
/cvs/openssh/compat.h,v
retrieving revision 1.35
diff -d -u -r1.35 compat.h
--- compat.h	3 Nov 2003 09:09:03 -0000	1.35
+++ compat.h	17 Jun 2004 22:02:55 -0000
@@ -43,6 +43,7 @@
 #define SSH_BUG_IGNOREMSG	0x00000100
 #define SSH_BUG_PKOK		0x00000200
 #define SSH_BUG_PASSWORDPAD	0x00000400
+#define SSH_BUG_PWDCHGREQ   0x00000402
 #define SSH_BUG_SCANNER		0x00000800
 #define SSH_BUG_BIGENDIANAES	0x00001000
 #define SSH_BUG_RSASIGMD5	0x00002000
Index: sshconnect2.c
==================================================================RCS file:
/cvs/openssh/sshconnect2.c,v
retrieving revision 1.127
diff -d -u -r1.127 sshconnect2.c
--- sshconnect2.c	15 Jun 2004 00:30:09 -0000	1.127
+++ sshconnect2.c	17 Jun 2004 22:02:55 -0000
@@ -767,11 +767,13 @@
 		    "no authentication context");
 
 	info = packet_get_string(NULL);
-	lang = packet_get_string(NULL);
+	if (!(datafellows & SSH_BUG_PWDCHGREQ)) {
+		lang = packet_get_string(NULL);
+		xfree(lang);
+	}
 	if (strlen(info) > 0)
 		logit("%s", info);
 	xfree(info);
-	xfree(lang);
 	packet_start(SSH2_MSG_USERAUTH_REQUEST);
 	packet_put_cstring(authctxt->server_user);
 	packet_put_cstring(authctxt->service);


[1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-21.txt

Scott Rankin wrote:
> I have found that this server,
> 3.1.0 F-SECURE SSH - Process Software SSH for OpenVMS
> does not follow the IETF secsh draft [1] related to the
> SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message. 
[...]
> Here is a patch that gets around this but I had some questions,
> 1. I wasn't sure I should combine this with the other F-Secure bug
listed
> (the one for the 1.3.2*)? Is there a regression test to test
> SSH_BUG_IGNOREMSG?
No, different bugs should use different flags.  I don't know if there's 
a regression test for BUG_IGNOREMSG.
> 2. I wasn't sure how much of the server version string was needed.
That will depend on which versions exhibit the problems.  Is it specific 
to the VMS implementation?  Can the vendor tell you?
> 3. The selection of SSH_BUG_PWDCHGREQ and it's define was totally
arbitrary
> by me.
>  #define SSH_BUG_PASSWORDPAD	0x00000400
> +#define SSH_BUG_PWDCHGREQ   0x00000402
>  #define SSH_BUG_SCANNER		0x00000800
Those bugs are bitmasks, so you should add it to the end of the list and 
use a value double the previous.  What you've done there is set 
SSH_BUG_PKSERVICE and SSH_BUG_PASSWORDPAD too.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

> <snip>
> debug1: Remote protocol version 1.99, remote software version 3.1.0
> F-SECURE SSH - Process Software SSH for OpenVMS
> debug1: no match: 3.1.0 F-SECURE SSH - Process Software SSH for
> OpenVMS </snip>
  This is not the latest version of SSH for VMS from Process.  The 
latest version is 3.2.0 for VMS (patchset SSH-062_A044 for Multinet 
v4.4 or SSH_V562P032 for TCPWare 5.6-2, not sure about the stand-alone 
product). Check to make sure your issue is present in the latest 
production release of SSH for VMS.

  Our setups may be different, but I don't get an error like you're 
seeing from an expired password.  I pushed my account to have the 
password expired and then tried to login.  I enter my password and I'm 
immediately prompted by the VMS auth system to change my password as 
its expired.  Here's my ssh -vvv output (based from your output):

debug1: Next authentication method: password
debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug2: channel 0: request pty-req
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
<....>
debug2: x11_get_proto: /usr/X11R6/bin/xauth 
-f /tmp/ssh-QgmoT18829/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 
untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/X11R6/bin/xauth 
-f /tmp/ssh-QgmoT18829/xauthfile list :0.0 . 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req
debug2: channel 0: request shell
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 100000 rmax 16384


Your password has expired; you must set a new password to log in

Old password:


This is the behavior I would expect.  I'm not 100% familiar with the 
section of the draft spec you're talking about, but this is how I would 
be expecting my VMS system to act.

Just for the record:

jason at sith jason $ telnet vmsbox 22
Trying xx.xx.xxx.xx...
Connected to vmsbox.
Escape character is '^]'.
SSH-1.99-3.2.0 F-SECURE SSH - Process Software MultiNet

-- 
Jason McCormick 
jason at devrandom.org
GPG Key ID: 96D6CF63