bugtraq - RE: Solaris telnet vulnberability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Feb 2007 10:56:10 -0800 (PST)
From: Nate Eldredge <nge@...hmc.edu>
To: Michael Wojcik <Michael.Wojcik@...rofocus.com>
Cc: bugtraq@...urityfocus.com
Subject: RE: Solaris telnet vulnberability - how many on your network?

On Mon, 19 Feb 2007, Michael Wojcik wrote:

>> From: Nate Eldredge [mailto:nge@...hmc.edu]
>> 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@...hmc.edu