Path: utzoo!attcan!uunet!mcsun!hp4nl!tuegate.tue.nl!al.ele.tue.nl!raymond
From: raymond@ele.tue.nl (Raymond Nijssen)
Newsgroups: comp.unix.questions
Subject: Re: Can the output to a terminal be monitored?
Message-ID: <509@al.ele.tue.nl>
Date: 11 Jun 90 16:31:42 GMT
References: <2784@syma.sussex.ac.uk> <270@demott.COM> <1990Jun3.011111.1589@virtech.uucp>
Sender: raymond@ele.tue.nl (Raymond Nijssen)
Organization: Eindhoven University of Technology, The Netherlands
Lines: 36

In article <1990Jun3.011111.1589@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes:
>>    Is there a way that I (as root) can "tap into" a user to monitor
>>terminal activity?  I specifcally would like to do this for the modem line.
>
>Not in software (unless you modify the software running on that port to 
>dump the data to a log file that you tail).  
>
>If what you want to do is to be able to abitrarily "tap" into a data line
>you must do it with hardware.  This can be done in several ways including
>
>
>-- 
>Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
>uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
>                                                Sterling, VA 22170 

There is another way, in software, without the need to adapt the software
running on the modemport, to monitor the terminal communication. This can
be achieved by constantly examining the kernel memory in which the getty
buffers are located. After some experiments, you can figure out where they
are located. Then, you can run a program acting as a spy. These programs
are used by crackers, and it's quite easy for them, since /dev/kmem is
world readable on most unix systems, for this is necessary for commands
like ps, which examines lots of kernels buffers also.

However, you need a lot of performance to avoid missing parts of the
communication via this line, so in practice, this method can only be used
on fast computers that are not heavily loaded, and it costs a great deal of 
CPU time, so i doubt whether it can be of use for monitoring an outgoing line.
Nevertheless, it should still be considered as a security hole, and I 
wonder if it has been fixed in rel. 4.

--
Raymond Nijssen
raymond@ele.tue.nl