Date: Sat, 23 Jan 1999 17:06:44 -0500 From: KuRuPTioN 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 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 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 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 To: BUGTRAQ@netspace.org Subject: Re: SSH 1.x and 2.x Daemon >> On Sat, 23 Jan 1999 17:06:44 -0500, KuRuPTioN 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: , 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 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 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 To: Jim Bourne 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 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 Reply-To: John Riddoch 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 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