Re: Fake ps detection program (system V and /proc enabled machines)

David Luyer (luyer@UCS.UWA.EDU.AU)
Wed, 17 Sep 1997 14:43:25 +0800

About (problems with) check_ps.c:

>From what I can see, this doesn't seem to allow a process to start in the
delay between checking the output of 'ps' and checking /proc - the obvious
race condition killing thousands of innocent processes. Much better would
be...

check /proc
check ps
note hidden processes and kill - if they have terminated they will be
gone already and it won't matter
if kill succeeds, log a message (a real hidden process; if it fails, it
was just a process which died)
note new processes and recheck /proc only for them - if they aren't
there, recheck ps, if they are still there they are a bogus process
(else they were a short-lived process)

the only race condition now is PID re-use.

Nicing yourself makes you stand out in the process list, which makes you
vulnerable to kills. It would be better to just sit at a standard
priority with a name like "in.telnetd" or so on...maybe a child process
called "-tcsh" (or "-rc" for Plan9ish users:) and attached to a terminal
:)

Syslogging your pid on start is also a pretty silly idea for a program
which is meant to hide - once someone has root, they will probably
check out the logs to see _what_ you are logging; it's easy enough to
check the ppid in ps list for the restarter/child process once one PID is
known, too. Don't assume crackers are stupid, hey, they would have
already got into root on your system before this program would be any use.

David.