Date: Fri, 4 Aug 89 13:27:15 PDT
Subject: Security Digest V1 #27

Security Digest Volume 1 Issue 27

subject(s):

            trace in SunOS 4.0.X
            trace
            `talk' security hole

------------------------------------------------------------------------

Date: Thu, 27 Jul 89 12:00:00 EDT
From: Tom Molnar <uunet!gpu.utcs.utoronto.ca!molnar>
Subject: trace in SunOS 4.0.X

My first impressions of the trace utility were favourable.  Now I am not
so sure.  A fellow coworker pointed out an alarming use of trace. Consider
what happens when a root user begins to trace a remote login session by
tracing a particular in.rlogind associated with someone's remote login
session.

The result is that everything is visible to the individual running
trace.  Not only what is typed on the keyboard, but also what is
written to the screen.  While it has been possible to do this in the
past, it required some level of skill to write the necessary code.  Now
Sun supplies the tool directly.

Consider the implications of this.  In my opinion, it's a pretty nasty
security problem.

------------------------------------------------------------------------

Date: Thu, 3 Aug 89 15:51:56 EDT
From: uunet!sirius.ctr.columbia.edu!seth
Subject: trace

on Thu, 27 Jul 89 12:00:00 EDT,
uunet!gpu.utcs.utoronto.ca!molnar said:

Tom> My first impressions of the trace utility were favourable.  Now I
Tom> am not so sure.  Consider what happens when a root user begins to trace a
Tom> remote login session by tracing a particular in.rlogind
Tom> associated with someone's remote login session.

You really should consider that anything that goes over the network
has been monitored.  It is incredibly easy to monitor the ethernet
for rlogin/telnet/ftp sessions with only etherfind, let alone any
specialized ethernet monitoring tools.

In any case, if you can't trust root on your local machine, you are
really in trouble since there are so many ways for root to monitor
what is happening.  If the root is a wizard, you are sunk without a
trace (or maybe with a trace(1) :-)

------------------------------------------------------------------------

Date: Thu, 3 Aug 89 15:35:13 EDT
From: uunet!sirius.ctr.columbia.edu!seth
Subject: `talk' security hole

First:

grover@aron.hac.com (Dean Grover (ird))  found an additional sideaffect to
a permissive (666) /etc/utmp.

If someone were to modify /etc/utmp so that it pointed to a file, and
then started a talk(1) session to that user the file /etc/utmp pointed
to, the file would be truncated.

This is more a denial-of-service hole since there is no currently
known way to gain access to the machine in this manner.  However it
certainly would be easy to crash the machine and keep it down for a
good day or so...

The essential problem is that Sun blew it when they decided to take
the easy approach (to sunview(1)) and make /etc/utmp 666.

  ------------------------

Second:

Hans Buurman writes:
>Is there any reason that I am missing why the rwalld cannot be partially
>fixed using /etc/inetd.conf (SunOS 4.0.x) ? Seems like

>walld/1         dgram   rpc/udp wait bin /usr/etc/rpc.rwalld   rpc.rwalld

Yes, as a matter of fact.  With user `bin' running rwalld, then the
hacker could overwrite any file owned by bin.  Programs such as
/usr/bin/login.  Not a good idea.  (Although this again would be
denial-of-service since they could not gain access to the computer)

------------------------------------------------------------------------

        End of Security Digest Volume 1 Issue 27
        **********************