Re: Solaris 2.x utmp hole
Andrew Prendergast (ap@budapest.ozonline.com.au)
Fri, 26 May 1995 02:04:24 +1000
>To all who have responded directly to me regarding this topic, I
>apologize for not returning your email. I wanted to verify a few
>things first, before commenting. Now, I am fairly certain that what I
>found is correct:
>
>After playing with the sample program, I RTFM. Actually, I RTFM before
>this to see what the *utxline() functions did. This time, I actually
>read every word! In the man page for getutxent(3C) I found:
>
> file. It returns a pointer to the utmpx structure. When
> called by a non-root user, pututxline() invokes a setuid()
> root program to verify and write the entry, since /etc/utmpx
> is normally writable only by root. In this event, the
> ut_name field must correspond to the actual user name asso-
> ciated with the process; the ut_type field must be either
> USER_PROCESS or DEAD_PROCESS; and the ut_line field must be
> a device special file and be writable by the user.
>
>Which program? On my box, it seems to be a pretty good secret. But
>being curious, I had to find out! I dynamically loaded the binary to
>see if running strings(1) on it would tell me. No luck. Then I used
>abort(3C) after the pututxline call to find a file name. That worked!
>It seems that when a user tries to do the update, the following
>program is run:
>
>-r-sr-xr-x 1 root bin 5996 Jul 16 1994 /usr/lib/utmp_update
>
>This is from a Solaris 2.4 on a pee cee. On my system, utmp_update
>will only allow me (the user) to update the ut_type field. It
>wouldn't let me update the ut_line field. I even put in "real" line
>names (look at your /dev directory and the 1001 symbolic links, Sun
>seems to have gone bananas with symbolic links again!).
>
>I called a friend at Sun in Mt. View. He confirmed this for me and that
>it is not a bug, but a feature!! :-) Then I asked some questions. I
>am going to paraphrase my questions and his answers (he asked to remain
>anonymous)--mainly because I don't take short-hand! I believe they are
>fairly accurate.
>
>Key: Me: Scott Barman (me!)
> SE: My friend the software engineer at Sun.
>
>Me: Why is this a "feature?"
>SE: For all the 1001 things that init now does, it doesn't "log out" a
>user when the user hangs up. The shells have all been hacked to catch
>all the signals and if they are going to exit, to update the utmp and
>utmpx files before they go. The init under SunOS did write logout
>messages to utmp when the process attached to the tty exited.
>
>Me: Is it possible for a user to make it look like he/she was not logged in?
>SE: No. Not unless someone hacked init. It generates a login message
>for all connections, including ftp. Actually, it's login and ftpd that
>make those entries, not init.
>
>Me: What about security? Isn't this dangerous not knowing who is on the
>system?
SE: Do you enforce the use of the "-ls" option with xterm? (The -ls
>starts a login shell to the window) Or do you run shelltool and
>command tool? How easy is it to run an rsh to start an xterm to get
>displayed on another system? I do it all the time, and my "login"
>information does not appear in the wtmp file. If these do not create
>umtp entries to begin with and you run them, why should this be a
>problem?
>
>Me: The way the manual reads I can change the ut_line field but my
>test program cannot. Why?
>SE: The man page says that? The man page is wrong! The wtmp_update
>program uses the user name and the line value to find the proper
>record for the user. If you do not pass the correct values, the
>wtmp_udate program will not do the update.
>
>Me: Is there anyway to make it look like someone is still logged in when
>they are not?
>SE: Haven't you seen this on SunOS? Xterms do this all the time!! (I
>have and they do) I don't think this is a security problem.
>
>Me: Some people have suggested this is a security hole. What do you say?
>SE: It's more of a pain in the behind than anything else. We've had
>customers call up and complain because they were relying on init to
>record the "logout" of their custom app, one that is started like a
>login shell (after login runs). But that's System V. We have to be
>SV compliant, so we do what the specs say and this is how the sources
>came to us.
>
>The rest of the conversation was "personal" in nature (he's an old
>friend! :-). However, he did convince me it wasn't as bad as it looks
>and is really not something to worry about.
>
>Then again he and I also agreed that the System V init was too bloated,
>did too much and we both couldn't find that much of an advantage in it
>over the old init in SunOS.
>
>I hope that answers the questions on this subject.
>
>scott barman
>scott@disclosure.com
>
>DISCLAIMER: I speak to anyone who will listen to me and I speak only for
myself!
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Andrew Prendergast http://www.ozonline.com.au/netcafe/ap
em: ap@ozonline.com.au ph: +61-3-9591-0982
finger: findap@gmurrh.ozonline.com.au <--to find my talk address
* HTML Authoring * Computer Security * System Administration *
Some put meaningful statements in their .sig. Here's mine.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a
mQCNAi+xH58AAAEEAL7YauUPVaI59ZYDspTc8cBDX7J5JNVzN0o8sGIp3YOwiWWC
mvngUUUO8NPFS2bAeHqQWLOnQjRsyiR682p6r+FEH9JdwIs2HWbiWhD4gXLbR2qM
6ch1TYDnVZ26KP+DnLc8quB87RoqVPnYzxilIApnM5yDoRLlitvhQ59hbOGVAAUR
tCdBbmRyZXcgUHJlbmRlcmdhc3QgPGFwQG96b25saW5lLmNvbS5hdT4=
=GfNr
-----END PGP PUBLIC KEY BLOCK-----