[9462] in bugtraq
Re: SSH 1.x and 2.x Daemon
daemon@ATHENA.MIT.EDU (Greg A. Woods)
Thu Feb 11 11:43:04 1999
Date: Tue, 9 Feb 1999 13:46:09 -0500
Reply-To: "Greg A. Woods" <woods@weird.com>
From: "Greg A. Woods" <woods@MOST.WEIRD.COM>
X-To: Tibor Toronyi <tibor@BLACK-OPS.UWINDSOR.CA>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Tibor Toronyi's message of "Monday, February 8,
1999 12:08:28 -0500" regarding "Re: SSH 1.x and 2.x Daemon" id
<199902081708.MAA09126@black-ops.uwindsor.ca>
[ On Monday, February 8, 1999 at 12:08:28 (-0500), Tibor Toronyi wrote: ]
> Subject: Re: SSH 1.x and 2.x Daemon
>
> 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)
I noticed this some time ago too (October 1997) and I even submitted
patches to not only avoid hard-coding the uncommonly used "*LK*" string
but to in fact to obey the real rule used by the standard Unix to lock
an account, which is to check if the length of the encrypted password
field.
No standard Unix 64-bit password can ever be encoded as anything but 11
characters plus 2 more for the "salt". Any field that is less than 13
characters can never match a valid password and will always result in a
locked account. To be ultra careful any field longer than 13 characters
should be searched for illegal characters, i.e. any non-alpha-numeric or
not '.' and '/'. However in practice one can also assume that any field
longer than 13 characters results in a locked account.
(This would then require custom checks to be added for systems such as
FreeBSD which don't use the standard Unix DES 64-bit password
encryption, but that's not so hard to do. I didn't submit patches for
FreeBSD at the time because I didn't use FreeBSD at the time.)
Of course the relative importance of this test is quite low as it only
assists in debugging on the server side. Note that in ssh-1.x sshd.c
only employs this test *after* check to see if the client user responded
with a valid password. Ssh-2.x checks if the account is locked before
going to the trouble of validating the supplied password, but I think
the effect is the same from the client's perspective. (There are too
many goto's in that code! ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
