sshd-1.x-2.x-login.txt

1999-08-17T00:00:00
ID PACKETSTORM:12378
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Sat, 23 Jan 1999 17:06:44 -0500  
From: KuRuPTioN <kuruption@CHA0S.COM>  
To: BUGTRAQ@netspace.org  
Subject: SSH 1.x and 2.x Daemon  
  
  
There seems to be incomplete code in the SSH daemon in both versions 1.2.27  
and 2.0.11 (only tested). The bug simply allows users who with expired  
accounts (in /etc/shadow) to continue to login even though other such  
services such as ftp and telnet deny access. Here is the log using 1.2.27  
(but the same happens with 2.0.11).  
  
[root@epicenter /etc]# chage -l lamer  
Minimum: 3  
Maximum: 30  
Warning: 5  
Inactive: -1  
Last Change: Jan 01, 1999  
Password Expires: Jan 31, 1999  
Password Inactive: Never  
Account Expires: Jan 22, 1999  
[root@epicenter /etc]# date  
Sat Jan 23 13:57:51 PST 1999  
[root@epicenter /etc]# telnet localhost  
Trying 127.0.0.1...  
Connected to localhost.  
Escape character is '^]'.  
login: lamer  
Password:  
Your account has expired. Please contact the system administrator.  
Connection closed by foreign host.  
[root@epicenter /etc]# ssh1 -l lamer localhost  
lamer@127.0.0.1's password:  
No mail.  
(lamer@epicenter) lamer>  
  
.......  
  
Now I wanted to try whether the account expiration worked using SSH, and it  
does. If a user's password has expired, then SSH will prompt following the  
login for the user to enter a new password and disconnect them if they fail  
to (like a telnet would).  
  
I have reported this problem to the SSH bug e-mail address about 2 weeks ago  
with no response.  
  
Current System Configuration:  
Linux 2.0.36  
Shadow Utilities 980724  
SSH 1.2.27 and 2.0.11 (both daemons)  
  
Any solutions (patch?) to this problem would be appreciated. Currently I  
just run a shell script to change the user's shell to deny them, but this  
shouldn't be necessary since this is one of the listed features of the  
Shadow Utilities.  
  
Thanks.  
Raymond T Sundland  
  
-------------------------------------------------------------------------------  
  
Date: Sun, 24 Jan 1999 14:39:30 -0800  
From: Jan B. Koum <jkb@BEST.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
This is not the case with ssh 1.1.26 running on FreeBSD 2.2.8  
If I expire an account:  
Expire [month day year]: January 1, 1999  
Then when I try to ssh in I just get:  
Permission denied.  
  
-- Yan  
  
-------------------------------------------------------------------------------  
  
Date: Sun, 24 Jan 1999 19:16:55 -0500  
From: KuRuPTioN <kuruption@CHA0S.COM>  
To: BUGTRAQ@netspace.org  
Subject: SSH Daemon  
  
  
Sorry, as to my prior post. I stated I was using 1.2.27, which is wrong  
since 1.2.27 has not been released yet. It is 1.2.26 release of SSH.  
  
Thanks  
  
Raymond T Sundland  
  
-------------------------------------------------------------------------------  
  
Date: Sun, 24 Jan 1999 19:31:34 -0800  
From: Alan Olsen <alan@CLUESERVER.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
At 05:06 PM 1/23/99 -0500, KuRuPTioN wrote:  
>There seems to be incomplete code in the SSH daemon in both versions 1.2.27  
>and 2.0.11 (only tested). The bug simply allows users who with expired  
>accounts (in /etc/shadow) to continue to login even though other such  
>services such as ftp and telnet deny access. Here is the log using 1.2.27  
>(but the same happens with 2.0.11).  
  
Furthermore, if the account is disabled in /etc/passwd and a user logs in  
via a public key, they are still allowed access. (So just diabling a user  
account is not enough anymore. You have to look for uses of public keys as  
well.)  
  
This may not exist in the 2.x series (I have not tested it there), but it  
does occur in the 1.2.x series. (I have not tested the latest version on  
this...)  
  
I would verify the above before panic, but I have seen it occur under one  
such install of 1.2.x. (I will have to look up the version. The drive was  
removed soon after due to hacker d00dz.)  
---  
| Bill Clinton - Bringing back the Sixties one Nixon at a time! |  
|"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: |  
| mankind free in one-key-steganography-privacy!" | Ignore the man |  
| | behind the keyboard.|  
| http://www.ctrl-alt-del.com/~alan/ |alan@ctrl-alt-del.com|  
  
-------------------------------------------------------------------------------  
  
From: Yutaka OIWA <yutaka@OIWA.SHIBUYA.TOKYO.JP>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
>> On Sat, 23 Jan 1999 17:06:44 -0500, KuRuPTioN <kuruption@CHA0S.COM> said:  
  
KuRuPTioN> There seems to be incomplete code in the SSH daemon in both versions 1.2.27  
KuRuPTioN> and 2.0.11 (only tested). The bug simply allows users who with expired  
KuRuPTioN> accounts (in /etc/shadow) to continue to login even though other such  
KuRuPTioN> services such as ftp and telnet deny access. Here is the log using 1.2.27  
KuRuPTioN> (but the same happens with 2.0.11).  
  
It seems to be a bug of configure script. As my quick observation  
for source code, possibly-vulnerable environment is  
  
- sshd 1.2.26 on  
* Linux, Irix5, Irix6, Ultrix, Convex  
- sshd 2.0.11 on  
* Almost all platform with account expiration and without  
usersec.h(?)  
  
To check whether the sshd is vulnerable, execute the command  
  
strings sshd | grep expire  
  
and see whether the message for ACCOUNT expiration is exist.  
(There may be a message for password expiration)  
  
Adding  
#define HAVE_STRUCT_SPWD_EXPIRE 1  
to appropriate header file (do after ./configure) may solve the  
problem (sorry, not tested).  
  
Detail:  
In ssh 1.2.26, checking shadow passwd existence is bypassed on  
some platforms. However, checking sp_expire existence is done  
in the bypassed section of configure script.  
In ssh 2.0.11, no checking seems to be done for sp_expire. (true?)  
  
--  
Yutaka Oiwa Yonezawa Lab., Department of Information Science,  
Faculty of Science, University of Tokyo.  
Email: <oiwa@is.s.u-tokyo.ac.jp>, <yutaka@oiwa.shibuya.tokyo.jp>  
PGP fingerprint = C9 8D 5C B8 86 ED D8 07 EA 59 34 D8 F4 65 53 61  
  
-------------------------------------------------------------------------------  
  
Date: Mon, 25 Jan 1999 15:22:03 -0500  
From: KuRuPTioN <kuruption@CHA0S.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
  
Hello again.  
  
I have been brainstorming with a few people and I have found a solution to  
the problem I was experiencing. This solution works in both SSH 1.2.26 (not  
1.2.27, as I was delusional that day) and SSH 2.0.11.  
  
In SSH 1.2.26 adding the -DHAVE_STRUCT_SPWD_EXPIRE to the Makefile in the  
top of the SSH tree with fix the problem.  
  
In SSH 2.0.11 adding the same -DHAVE_STRUCT_SPWD_EXPIRE to  
ssh-2.0.11/lib/sshsession/Makefile. In both case, I added it to the 'defs  
=' section and it worked fine, but maybe there is a cleaner way to do this.  
  
In regards to -with-login, I have tried it and gotten errors not allowing me  
to login at all. I do not remember the exact problem, but I know it did not  
work. (I am too lazy right now to replicate the error).  
  
Thanks to everyone who responded and lent me a hand.  
  
Raymond T Sundland  
  
-------------------------------------------------------------------------------  
  
Date: Mon, 25 Jan 1999 14:24:00 -0700  
From: Jim Bourne <jbourne@AFFINITY-SYSTEMS.AB.CA>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
Parts/Attachments:  
1 Shown 72 lines Text  
2 OK ~1.4 KB Text, "Expiry Patch"  
----------------------------------------  
  
On Sat, 23 Jan 1999, KuRuPTioN wrote:  
  
> There seems to be incomplete code in the SSH daemon in both versions 1.2.27  
> and 2.0.11 (only tested). The bug simply allows users who with expired  
> accounts (in /etc/shadow) to continue to login even though other such  
> services such as ftp and telnet deny access. Here is the log using 1.2.27  
> (but the same happens with 2.0.11).  
  
Hi,  
I had emailed them about this and here is the response:  
  
________________  
  
Date: Tue, 7 Jul 1998 22:38:08 +0300 (EET DST)  
From: Tero Kivinen <kivinen@ssh.fi>  
To: Jim Bourne <jbourne@island.net>  
Subject: ssh on linux  
Status: U  
  
Jim Bourne writes:  
> I've been playing with SSH on my home system, and found a problem with  
> compiling it under Linux 2.0.33 (redhat 4.2 in this case). Since shadow  
> support can be turned on fairly easily (pwconv5) and the struct spwd does  
> include shadow aging and expiry information, I thought it would be better to  
> have these turned on when using autoconf.  
  
Linux shadow password maintainer said earlier that we must turn off  
shadow password checking and always use the shadow password functions,  
just so that you can turn shadow password on later. Currently the  
configure.in checks that if we are in linux and we have getspnam  
function then we turn shadow password on always, and otherwise we  
don't turn it on. So I didn't remove that  
no_shadows_password_checking=yes line from the configure.  
  
[snip]  
  
--  
kivinen@iki.fi Work : +358-9-4354 3218  
SSH Communications Security http://www.ssh.fi/  
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/  
----------------------  
  
They do know that it does work under Linux and choose to leave it out.  
  
> Any solutions (patch?) to this problem would be appreciated. Currently I  
> just run a shell script to change the user's shell to deny them, but this  
> shouldn't be necessary since this is one of the listed features of the  
> Shadow Utilities.  
  
I have attached a patch, that simply checks for the presence of shadow  
passwords and sets the appropriate defines. It does work on Linux 2.0.37pre  
and redhat 5.1/5.2. You will have to have autoconf and re-run it to build a  
new configure script.  
  
Regards  
Jim  
  
>  
> Thanks.  
> Raymond T Sundland  
>  
  
--  
  
--  
James Bourne | Email: jbourne@affinity-systems.ab.ca  
Affinity Systems Inc. | WWW: http://www.affinity-systems.ab.ca  
Everything Unix | Linux: The choice of a GNU generation  
----------------------------------------------------------------------  
Unix System Administration, System programming, Network Administration  
  
----------[begin patch]----------  
  
diff -ruN ssh-1.2.26.orig/config.h.in ssh-1.2.26/config.h.in  
--- ssh-1.2.26.orig/config.h.in Tue Nov 3 09:11:16 1998  
+++ ssh-1.2.26/config.h.in Tue Nov 3 09:08:43 1998  
@@ -123,6 +123,9 @@  
/* Define this to be the path of the rsh program to support executing rsh. */  
#undef RSH_PATH  
  
+/* Define this to be the path to the passwd program */  
+#undef PASSWD_PATH  
+  
/* Define this to be the path of the xauth program. */  
#undef XAUTH_PATH  
  
diff -ruN ssh-1.2.26.orig/configure.in ssh-1.2.26/configure.in  
--- ssh-1.2.26.orig/configure.in Tue Nov 3 09:11:16 1998  
+++ ssh-1.2.26/configure.in Tue Nov 3 09:08:43 1998  
@@ -200,7 +200,6 @@  
if test $ac_cv_func_getspnam = yes; then  
AC_DEFINE(HAVE_ETC_SHADOW)  
fi  
- no_shadows_password_checking=yes  
AC_CHECK_FUNCS(pw_encrypt, pwencrypt=yes)  
if test $ac_cv_func_pw_encrypt = no; then  
AC_CHECK_LIB(shadow, pw_encrypt, [  
@@ -459,6 +458,11 @@  
AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")  
fi  
  
+AC_PATH_PROG(PASSWD_PATH, passwd)  
+if test -n "$PASSWD_PATH"; then  
+ AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")  
+fi  
+  
AC_PATH_PROG(XAUTH_PATH, xauth)  
if test -n "$XAUTH_PATH"; then  
AC_DEFINE_UNQUOTED(XAUTH_PATH, "$XAUTH_PATH")  
@@ -532,6 +536,7 @@  
else  
AC_MSG_RESULT(no)  
fi  
+  
  
if test -z "$no_shadows_password_checking"; then  
AC_MSG_CHECKING(for shadow passwords)  
  
-------------------------------------------------------------------------------  
  
Date: Mon, 25 Jan 1999 20:40:09 +0100  
From: Linux Mailing Lists <linux@AIIND.UPV.ES>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
Hello,  
  
> > There seems to be incomplete code in the SSH daemon in both versions 1.2.27  
> > and 2.0.11 (only tested). The bug simply allows users who with expired  
> > accounts (in /etc/shadow) to continue to login even though other such  
> > services such as ftp and telnet deny access. Here is the log using 1.2.27  
> > (but the same happens with 2.0.11).  
>  
> This is not the case with ssh 1.1.26 running on FreeBSD 2.2.8  
> If I expire an account:  
> Expire [month day year]: January 1, 1999  
> Then when I try to ssh in I just get:  
> Permission denied.  
  
  
There's a configure parameter to use the "usual" /bin/login program  
instead of the login procedure implemented with ssh:  
  
--with-login[=PATH] Use login -f to finish login connections.  
  
On one hand, a possible fix (temporal, of course) is to compile sshd with  
support for /bin/login. The features of the shadow-suite will be back.  
  
On the other hand, SSH 1.2.26 seems to implement the expiration date of  
accounts (grep expire sshd.c), but I don't know if it does it ok.  
  
Greetings,  
  
Sergio  
  
-------------------------------------------------------------------------------  
  
Date: Tue, 26 Jan 1999 09:25:36 +0000  
From: John RIddoch <jr@SCMS.RGU.AC.UK>  
Reply-To: John Riddoch <jr@master.scms.rgu.ac.uk>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
>Furthermore, if the account is disabled in /etc/passwd and a user logs in  
>via a public key, they are still allowed access. (So just diabling a user  
>account is not enough anymore. You have to look for uses of public keys as  
>well.)  
  
You get the same effect if a user has ~/.rhosts file using rsh/rlogin  
  
>This may not exist in the 2.x series (I have not tested it there), but it  
>does occur in the 1.2.x series. (I have not tested the latest version on  
>this...)  
>  
>I would verify the above before panic, but I have seen it occur under one  
>such install of 1.2.x. (I will have to look up the version. The drive was  
>removed soon after due to hacker d00dz.)  
  
I can verify that using keys and ssh-agent under ssh-2.0.11 (Sparc Solaris  
2.6) allows login if the (NIS) account has been disabled.  
  
However, this is no less or greater a problem than the .rhosts file. There  
are tools to detect for .rhosts files in disabled accounts; perhaps the  
writers of those scripts might be able to add a check for public keys under  
ssh?  
  
--  
John Riddoch Email: jr@scms.rgu.ac.uk Telephone: (01224)262730  
Room C4, School of Computer and Mathematical Science  
Robert Gordon University, Aberdeen, AB25 1HG  
"Yoda of Borg are we: Futile is resistance. Assimilate you, we will"  
  
-------------------------------------------------------------------------------  
  
Date: Mon, 8 Feb 1999 12:08:28 -0500  
From: Tibor Toronyi <tibor@BLACK-OPS.UWINDSOR.CA>  
To: BUGTRAQ@netspace.org  
Subject: Re: SSH 1.x and 2.x Daemon  
  
----- KuRuPTioN wrote -----  
> I have been brainstorming with a few people and I have found a solution to  
> the problem I was experiencing. This solution works in both SSH 1.2.26 (not  
> 1.2.27, as I was delusional that day) and SSH 2.0.11.  
>  
> In SSH 1.2.26 adding the -DHAVE_STRUCT_SPWD_EXPIRE to the Makefile in the  
> top of the SSH tree with fix the problem.  
  
As a side note (after checking into this problem), I noticed that the  
server code ONLY checks for "*LK*" in the password field to see if the  
person is disabled. Not sure of other places but we've had to modify the  
code a bit so that instead of  
  
if ((strncmp(passwd,"*LK*", 4) == 0)  
  
I'd recommend  
  
if ((strchr (passwd, '*') != (char *) NULL)  
  
--------------------------------------------------------------------------  
Tibor Toronyi voice: (519) 253-4232 ext. 2753  
Information Technology Services fax: (519) 973-7083  
University of Windsor email: tibor@uwindsor.ca  
Windsor, Ontario, Canada /* Live long and prosper. */  
N9B 3P4 /* Mr. Spock */  
  
PGP Public Key: finger tibor@black-ops.uwindsor.ca  
http://black-ops.uwindsor.ca/pgp  
  
`