From time to time paranoia catches up with me, and while I run chkrootkit from time to time, any rootkit I would write would remove it automatically from any cron job or simply remove or hack the chkrootkit script.

That's why I extracted the most interesting functionality of chkrootkit into a Perl script.

The following Perl script checks if there are processes running (in /proc/$pid/exe) for which the binary does not exist anymore. Most likely this is either a service that I upgraded and forgot to restart or it is a trojan/rootkit that got installed, started itself and then removed the binaries to hide the traces.

This will not protect against loadable kernel modules or any other code that dosen't live within its own separate process.

#!/usr/bin/perl -w use strict; my $i; for $i (0..65536) { #test -f $i/cmdline && (cat $i/cmdline; echo $i); if (-f "/proc/$i/exe") { my $target = readlink "/proc/$i/exe"; if (! -f $target) { open F, "< /proc/$i/cmdline"; my @data = <F>; print "ALERT: '@data' is running (pid $i)\n"; close F; local $/ = "\x00"; open F, "< /proc/$i/environ"; @data = <F>; print "ALERT: 'environment: @data'\n"; close F; }; }; };

Update: theorbtwo noted the bug about the missing localization of $/, which will play bad with the my @data = <F> as soon as you have more than one file.

As a lesson, you should always use local on the punctuation variables, unless you have a compelling reason.

Update 2: PodMaster noted s!(doesn't) (within)!$1 live $2!

Update 3: People seem to be reading this note - s!dosen't!doesn't!

Replies are listed 'Best First'.
Re: Checking for unlinked process executables
by liz (Monsignor) on Apr 04, 2004 at 20:14 UTC
    Nice! I've got two style nits that I would have used had I written this code:
    1. I try to use significant variable names: $i -> $pid
    2. I always try to reduce the number of indent levels: if -> next
    So the body of the code would look like this if I had written it:
    my $pid; for $pid (0..65536) { #test -f $pid/cmdline && (cat $pid/cmdline; echo $pid); next unless -f "/proc/$pid/exe"; my $target = readlink "/proc/$pid/exe"; next if -f $target; open F, "< /proc/$pid/cmdline"; my @data = <F>; print "ALERT: '@data' is running (pid $pid)\n"; close F; local $/ = "\x00"; open F, "< /proc/$pid/environ"; @data = <F>; print "ALERT: 'environment: @data'\n"; close F; };

    Liz

Re: Checking for unlinked process executables
by Anonymous Monk on Apr 05, 2004 at 01:17 UTC

    /me jumps on the "here's a handy dandy rewrite for you" bandwagon:

    #!/usr/bin/perl -w use strict; for my $pid (0 .. 65536) { next if ( ( not -f("/proc/$pid/exe") ) || ( -f( readlink("/proc/$pid/exe") ) ) ); open( my $cmdline, '<', "/proc/$pid/cmdline" ) or die "open failed: $!"; my @cmdline = <$cmdline>; close( $cmdline ) or die "close failed: $!"; print "ALERT: '@cmdline' is running (pid $pid)\n"; { local $/ = "\x00"; open my $env, '<', "/proc/$pid/environ" or die "open failed: $!"; my @env = <$env>; close( $env ) or die "close failed: $!"; print "ALERT: environment: '@env'\n"; } }
Re: Checking for unlinked process executables
by DrHyde (Prior) on Apr 06, 2004 at 08:50 UTC
    /proc/PID/exe is a symlink to a filename, not to a file. So you can't tell just by looking at it whether the executable stored at (eg) /usr/sbin/apache is really the one that is running. Better, I think, to do something like this pseudo-code:
    foreach PID lsof -p PID | grep FILENAME and parse out the inode number stat FILENAME do the inodes match?
    still not foolproof, of course. It's also far more portable to use utilities like lsof than to grovel around in /proc which doesn't even exist on some systems. But on Linux/x86 (and presumably Linux/others too) all the information you need is in /proc/PID/maps.