From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Newsgroups: alt.security,alt.sys.sun,comp.unix.admin
Subject: A security problem in SunOS 4.1.1 and earlier with in.comsat and /etc/utmp
Message-ID: <1991Aug21.152339.11436@nntp.hut.fi>
Date: 21 Aug 91 15:23:39 GMT
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland

[ followups to alt.security ]

I hope that somebody with SunOS source can make a fixed version of
in.comsat available for the net.  Still, the suggested fixes #2 and #3
are a good idea to do anyway.  They apply for generic BSD-based
systems as well.

This bug has been reported to Sun and CERT in March of 1991 by me.  It
has also been reported to Sun and CERT in May of 1990 by NASA.

More information can be found in manual pages in.comsat(8), inetd(8),
inetd.conf(5) and utmp(5).


The rest of this article is quoted from the bug report I sent.

>From jkp Fri Mar 22 21:10:44 1991
From: Jyrki Kuoppala <jkp@cs.hut.fi>
Subject: Serious trouble with SunOS comsat / world-writable utmp
Return-Receipt-To: <jkp@cs.hut.fi>
Organization: Helsinki University of Technology, Finland.

> Newsgroups: alt.security
> From: jkp@cs.HUT.FI (Jyrki Kuoppala)
> Subject: A much more serious problem w/ world-writable utmp & comsat
> Message-ID: <1991Mar22.184621.5049@santra.uucp>
> Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
> Organization: Helsinki University of Technology, Finland
> References: <1991Mar20.011741.13849@santra.uucp> <1991Mar20.185915.27296@santra.uucp> <7378@idunno.Princeton.EDU> <1991Mar22.162102.3302@santra.uucp>
> Date: Fri, 22 Mar 91 18:46:21 GMT
> Lines: 18
> 
> Seems like comsat with world-writable utmp and/or /usr/spool/mail
> opens up a real can of worms.  It appears to be possible to overwrite
> any executable-to-owner file.  It appears to be possible to gain root
> access with only an ordinary account on the machine - and if you run a
> non-restricted tftp daemon, on some situations also even with no
> account on the machine.
> 
> Suggested fix(es):
> 
> 1. Don't run comsat for now until all of this is sorted out and proper fixes
>    are available.
>    This perhaps makes the situation somewhat better even if you don't change
>    utmp and /usr/spool/mail protections.  But it won't fix all of the
>    security problems.
> 2. Don't keep /etc/utmp writable to the world.
> 3. Don't keep /usr/spool/mail writable to the world.
> 
> //Jyrki

Works like this:

- make a symlink /tmp/x pointing to the executable file you want to overwrite.
  If you want to gain root access make this a file that root will execute.
- mail a message to root with a shell script you want to write over
  the executable with (if root mail is not redirected).  If root mail
  is redirected, probably there is no /usr/spool/mail/root and you can
  just create your own.  Might be also possible to use \root to write
  to /usr/spool/mail/root even if it is forwarded.  If /usr/spool/mail
  is write protected and root mail is forwarded to someone else,
  it might not be that easy - but anyway, if that's the case then
  anyone else's files (for those whose mail is not forwarded) can be
  overwritten.
- edit /etc/utmp to have an entry for user `root' with tty line
  `../tmp/x'
- send a message `root@offset' with the right offset to comsat.  It
  will overwrite the file /tmp/x points to - while adding some garbage
  like `New mail for root has arrived'.
- when root runs the overwritten command, shell will complain somewhat
  about the garbage lines but the lines from the mail which are proper shell
  commands (with for example ; at the end of line to make the ^M not
  cause trouble) will be executed.

Tested on SunOS 4.1 and 4.1.1.  Might not directly concern systems
where utmp and /usr/spool/mail are not world-writable, but it'd be a
good idea to make comsat do some additional checking anyway.  Also, on
many systems with writable /usr/spool/mail it's possible to read
other's mail by mv'ing their mail files to yourself and then sending
some mail to yourself (if I remember right).  This could be used to
read other files also, if on the same file system as /usr/spool/mail.
So the advice to chmod o-w /usr/spool/mail still holds.

People at Sun, please ack this message.

//Jyrki