[583] in SIPB_Linux_Development
Re: telnetd/login hole
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu May 26 11:06:13 1994
Date: Thu, 26 May 1994 11:05:55 -0400
To: David Krikorian <dkk@MIT.EDU>
Cc: svalente@MIT.EDU, linux-dev@MIT.EDU
In-Reply-To: David Krikorian's message of Thu, 26 May 94 05:14:09 -0400,
<9405260914.AA28180@hal-2000.MIT.EDU>
From: "Richard Basch" <basch@MIT.EDU>
Date: Thu, 26 May 94 05:14:09 -0400
From: David Krikorian <dkk@MIT.EDU>
Home: 47 Lake St., Arlington, MA 02174, (617) 646-9289, -9269 (fax)
> Well, none of the Linux systems I use were affected by this, but I'm
> curious: does anyone know _exactly_ where the hole was? I guess the
> first question is: what is the "login -f" flag supposed to do?
As I understand it, "login -f username" is like "su username" (for
root) except that it runs the .login, and otherwise acts as a normal
login for username.
I'm somewhat concerned by the concensus that our machines aren't
affected by this security hole. I've only checked on two linux
systems, both Slackware 1.1, I think, and both were vulnerable. I'm
actually getting quite spoiled by never having to type my password (or
the root password).
BTW, the problem is that /bin/login is allowing you to give, at the
login: prompt, "-fusername" as the username. Note there isn't a space
in there. By requiring a space, I believe the problem (mostly?)
evaporates.
Basically, the problem is that "-f<user>" (as one argument) was
equivalent to "-f user" (two arguments). If you require it to be two
arguments, then the first will not succeed and using the space in a
quoted argument over the network or at the console prompt will also be
treated as one long argument, and also not succeed.
-Richard
