mailing list archives
Re: Solaris 2.x utmp hole
From: scott () Disclosure COM (Scott Barman)
Date: Mon, 22 May 1995 14:51:27 -0400 (EDT)
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
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
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
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 () disclosure com
DISCLAIMER: I speak to anyone who will listen to me and I speak only for myself!
- Re: From the moderator: READ Please, (continued)