Lucene search
Packet StormPACKETSTORM:12378HistoryAug 17, 1999 - 12:00 a.m.
sshd-1.x-2.x-login.txt
1999-08-1700:00:00
Packet Storm
packetstormsecurity.com
41
`Date: Sat, 23 Jan 1999 17:06:44 -0500
From: KuRuPTioN <[email protected]>
To: [email protected]
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
[email protected]'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 <[email protected]>
To: [email protected]
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 <[email protected]>
To: [email protected]
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 <[email protected]>
To: [email protected]
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/ |[email protected]|
-------------------------------------------------------------------------------
From: Yutaka OIWA <[email protected]>
To: [email protected]
Subject: Re: SSH 1.x and 2.x Daemon
>> On Sat, 23 Jan 1999 17:06:44 -0500, KuRuPTioN <[email protected]> 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: <[email protected]>, <[email protected]>
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 <[email protected]>
To: [email protected]
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 <[email protected]>
To: [email protected]
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 <[email protected]>
To: Jim Bourne <[email protected]>
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]
--
[email protected] 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: [email protected]
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 <[email protected]>
To: [email protected]
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 <[email protected]>
Reply-To: John Riddoch <[email protected]>
To: [email protected]
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: [email protected] 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 <[email protected]>
To: [email protected]
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: [email protected]
Windsor, Ontario, Canada /* Live long and prosper. */
N9B 3P4 /* Mr. Spock */
PGP Public Key: finger [email protected]
http://black-ops.uwindsor.ca/pgp
`