chkproc giving false positives for threads?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I run the latest chkrootkit/chkproc on my system and it reports 55
processes hidden from ps.

I look in the /proc directory and I don't see any hidden files.

I do a find /proc  and grep for the suspicious process numbers, and
they all turn out to be (non-hidden) entries in a subdirectory:


AFAIK, the "task" subdir is for threads.  And, the main process in
question is a Java server process (tomcat) which most likely DOES do

Could this be an oversight by the authors of chkproc?

Re: chkproc giving false positives for threads?

On 19 Oct 2006, in the Usenet newsgroup, in article

Quoted text here. Click to load it

From the README file:

 10/28/2005 - Version 0.46a chkproc.c: bug fix for FreeBSD: chkproc
                            was sending a SIGXFSZ (kill -25) to init,
                            causing a reboot.
 10/10/2006 - Version 0.47  chkproc.c: bug fixes, use of getpriority(),
                            Enye LKM detected. chkrootkit: crontab
                            test, Enye LKM and Lupper.Worm detected,
                            minor bug fixes.

From chkrootkit-0.47/chkproc.c:

  2005/10/28 - Bug fix for FreeBSD: chkproc was sending a SIGXFSZ (kill -25)
               to init, causing a reboot.  Patch by Nelson Murilo.
               Thanks to Luiz E. R. Cordeiro.

  2005/11/15 - Add check for Enye LKM - Nelson Murilo

  2005/11/25 - Fix for long lines in PS output - patch by Lantz Moore

  2006/01/05 - Add getpriority to identify LKMs, ideas from Yjesus(unhide) and
               Slider/Flimbo (skdet)

  2006/01/11 - Fix signal 25 on parisc linux and return of kill() -
               Thanks to Lantz Moore

Doesn't look as if anything was changed that would cause this.

Quoted text here. Click to load it

Terminology - it's not talking about dot-files, but a situation where
/bin/ps has been altered to hide certain process directories - you'd still
be able to detect them by other means.

Quoted text here. Click to load it

Given the philosophy of the application - such as testing for file names
used by worms over six years ago (don't you think the rootkit author might
have changed "/tmp/.../a" or "/tmp/.../r" to perhaps "/tmp/.../A" or
similar - defeating the detection of that specific worm), I certainly
would not be surprised of that.  Your best bet would be to mail the author
and ask.  See section 9 of the README file.

I suppose I should now go look to see if rkhunter (another windoze-wannabe
rootkit detector at /) has been updated. I've also
seen another tool called Zeppoo ( ), but it's quite
new and may not be ready for prime time yet.

        Old guy

Site Timeline