RE: Solaris telnet vulnberability - how many on your network?
On Mon, 19 Feb 2007, Michael Wojcik wrote:
From: Nate Eldredge [mailto:nge@xxxxxxxxxx]
Sent: Friday, 16 February, 2007 21:42
On Sat, 17 Feb 2007, Darren Reed wrote:
Solaris's /bin/login has never supported the "-f" command line
option
until Solaris 10 (RTFM) so this exploit was just plain not possible.
That is not correct. On a Solaris 8 box the -f option is accepted
without
error.
Which does not show that it's "supported". /bin/true accepts the -f
option, too.
I have now set up a virtual Solaris 8 box to test this with root access,
and it appears you are correct. When run as root, "login -f root"
presents a login prompt, just like login without arguments. So it is not
"supported" in the sense of having the Solaris 10 documented behavior.
That /bin/true accepts and ignores any and all options is a feature. For
instance, it is sometimes convenient to replace another command by a
symlink to /bin/true (or /bin/false) in order to test the effect of the
command succeeding (or failing), in which case /bin/true might receive
arbitrary command line arguments. This does not apply to /bin/login,
which in general does reject unknown options.
I don't have root so I can't verify that it does the right thing,
You're using a Solaris 8 system with no entry in /etc/passwd for UID 0?
Extraordinary.
He'll be here all week, folks!
but at least as a normal user "login -f asdfasdf" does nothing
I haven't looked at the Solaris 10 login sources, but IIRC on AIX, this
bug required that the username be appended to the -f ("-froot", not "-f
root").
That is only necessary to get it passed through telnet as a username.
The -f option to /bin/login itself is parsed by getopt(3) and can be given
with or without a space before its argument.
while "login" without arguments presents a prompt.
And what does "login -q asdfasdf" do? What about "login -z asdfasdf"?
login: illegal option -- q
Usage: login [-h|-r] [ name [ env-var ... ]]
Standard getopt behavior; unknown options are rejected.
My point is just that it's peculiar that -f should have been implemented
so far as adding it to the getopt list and giving it some sort of effect
(since after all it does change the behavior of the command when run as
non-root) without implementing the "right" semantics or documenting it.
In a setuid utility, no less. I am curious to know how this came about,
and exactly what -f does.
Using "strings" to look at the getopt option list reveals that an
undocumented "-a" option also exists. I don't know what it does, either.
More material for the backdoor conspiracy theorists, I suppose.
Fortunately there doesn't appear to be a "-nsakey" option.
--
Nate Eldredge
nge@xxxxxxxxxx