From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Newsgroups: comp.unix.admin
Subject: Re: World-writable /etc/utmp (was something else)
Message-ID: <1991Aug20.022920.24954@nntp.hut.fi>
Date: 20 Aug 91 02:29:20 GMT
References: <SHERK.91Aug15120343@nmc.cit.cornell.edu> <19526@darkstar.ucsc.edu> 	<8214@tekgen.BV.TEK.COM> <1991Aug17.121526@thuja.gsfc.nasa.gov> 	<1991Aug18.061739.8097@nntp.hut.fi> 	<SHERK.91Aug18130621@nmc.cit.cornell.edu> 	<1991Aug18.181134.8266@world.std.com> <BR
Organization: Helsinki University of Technology, Finland

In article <mattson.682622518@ishin>, mattson@ishin (Jim Mattson) writes:
>Aside from comsat abuses, are there any other serious problems with a
>world-writable utmp?  If comsat is the only real problem, I'd rather
>just disable comsat on workstations, rather than breaking other things
>(in our environment, mail is never actually delivered on a workstation,
>so disabling comsat is a nop).  Of course, you can spoof other users by
>writing bogus entries to /etc/utmp, but what mechanisms other than comsat
>actually allow you to access/destroy files that you wouldn't be able to
>otherwise?  Am I missing something obvious?

I found the following paragraph from my old archives:

It seems probable that also talkd has this hole, although with talkd
you can write only to files which are writable to the group (along the
normal tty permissions).

Many programs will crash if users write random garbage in utmp - there
are probably a few security holes which haven't been found yet that
can be opened by this.  Wall / rwall for example still crashes if utmp
contains garbage (Sun seems to have fixed it in quite a non-obvious
way, I did some RTFB'ing to see what it does).

Somebody also told me that syslog, if configured to write messages to
root, operator etc, can also be used to break security.


Here's a description about 4.1.1 rwall / wall, nothing important, skip if
you aren't pervertly interested in all those network daemons ;-):

My understanding is that they didn't fix rpc.rwalld, but made
/bin/wall first stat() the ut_line and check it's a char special
device, then open it and do isatty() on it.  If either of these fails,
it refuses to write to the file and syslog()s an error message.

But /bin/wall still has bugs - it copies the ut_line to a static buffer
with strcpy(), making it possible to overwrite wall's private
variables with as many kb of data in utmp as you want.  Before I took
the time to disassemble /bin/wall properly, I thought the first stat()
was open() and though it forgot to close the ut_line file when
returning, and thought: hey, this is easy, just overwrite _iobuf with
some suitable data to make _cleanup() on exit() to write something
nice to the file which wall forgets to close.

But it does close the file if the isatty() fails, so this scheme
doesn't work (would have been fun).  There might be another way, but I
didn't think of one.  In addition to overwriting _iobuf (or is it
_iob), you can also overwrite the strings it syslog()s and perhaps
something else - but I didn't find overwriting these very useful in
breaking security.

I didn't bother to check thoroughly, but on a quick look at talkd it
seems talkd might have the same problem.  I wouldn't be surprised if
other daemons or scripts run from cron or commands run by root can be
fooled to do something nasty with a utmp containing some suitable data
- some status programs like w or finger dump core on a corrupted utmp,
and if these are run by root you might be able to write some code or
something in them to compromise security (a la the fingerd buffer
overflow the internet worm was using).

//Jyrki