When I scan my machine with chkrootkit I notice that it always says for one of them:

Checking `syslogd'...                                       not tested

Why is this not tested for? Should this be tested for? And if it is a good thing for it to test for, how can I get it to test for it?

OS Information:

Description:    Ubuntu 14.10
Release:    14.10

Package Information:

  Installed: 0.49-5ubuntu1
  Candidate: 0.49-5ubuntu1
  Version table:
 *** 0.49-5ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ utopic/universe amd64 Packages
        100 /var/lib/dpkg/status
  • You're going to become the resident expert at finding viruses and rootkits if you continue like this (both Q&A upvoted) – Fabby Apr 9 '15 at 9:10

This happens because chkrootkit looks for an executable named syslogd in several common locations, but since Ubuntu uses rsyslog, its syslog daemon is instead called rsyslogd.

To check that the syslog daemon on your machine specifically is called rsyslogd rather than syslogd, you can run locate syslogd (though of course, if you did have a rootkit, it could cause wrong results to be reported by this command too):

ek@Io:~$ locate syslogd

To verify that this is why chkrootkit is not testing the syslog daemon, you can run chkrootkit with the -d flag (for debug mode) and send a copy of the output to a file:

sudo chkrootkit -d |& tee ~/chkrootkit.log

Then open the log file in a text editor and examine the debug output between the Checking `syslogd'... and not tested messages. On my machine it looks like this (on yours I expect it will be similar):

Checking `syslogd'...                                       + chk_syslogd
+ SYSLOG_I_L=/usr/lib/pt07|/dev/pty[pqrs]|/dev/hd[als][0-7]|/dev/ddtz1|/dev/ptyxx|/dev/tux|syslogs\.h
+ loc syslogd syslogd /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /sbin /usr/sbin /lib /usr/lib /usr/libexec .
+ thing=syslogd
+ shift
+ dflt=syslogd
+ shift
+ :
+ test -f /usr/local/sbin/syslogd
+ :
+ test -f /usr/local/bin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /usr/bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /lib/syslogd
+ :
+ test -f /usr/lib/syslogd
+ :
+ test -f /usr/libexec/syslogd
+ :
+ test -f ./syslogd
+ [ / = / ]
+ echo syslogd
+ exit 1
+ CMD=syslogd
+ [ ! -r syslogd ]
+ return 2
+ [  = t ]
+ echo not tested
not tested

Since a file called syslogd does not exist in any of those locations (or at all), there is nothing for it to test.

A possible partial workaround would be to create a symbolic link at one of those locations to the real ryslogd executable. I consider this only a partial solution because I don't know the details of what chkrootkit checks (or should check), or if there's anything special that it should be doing to properly inspect rsyslogd, or if it really works properly when inspecting symlinks and recently created files. chkrootkit does report successfully checking syslogd when I do this, though:

ek@Io:~$ sudo ln -s /usr/sbin/rsyslogd /usr/local/sbin/syslogd
ek@Io:~$ sudo chkrootkit | grep syslogd
Checking `syslogd'...                                       not infected

The sbin subdirectory of /usr/local might not already exist, in which case you can create it. Either way, I do suggest removing the syslogd symlink after using it.

In any case the real solution is as bodhi.zazen says--this should be reported as a bug against the chkrootkit package in Ubuntu. The way I suggest you report the bug is to:

  1. Read this guide, if you haven't already. It provides excellent guidance on writing bug reports. (This question is another good resource.)
  2. Run ubuntu-bug chkrootkit.
  3. Apport will say it is "Collecting problem information." When it's done, click "Send." This will open a new browser tab where you can report the bug.
  4. Include information documenting the output of chkrootkit when the problem occurs. I recommend attaching a log showing its output, preferably including debug output. You could attach the log file created if/when you ran sudo chkrootkit -d |& tee ~/chkrootkit.log (see above). You might also reproduce the small, most relevant part in the text of the bug report itself.
  5. Submit the bug report.
  6. Optionally, if you comment on this answer, I'll go to the bug report and indicate that I am also affected--as I have been able to reproduce the bug on my system. I may also be able to provide additional information--for example, I can confirm it occurs on the 15.04 Beta, and if you don't have time to produce and attach a log, I could do so. (But I'd encourage you to provide as much relevant information as you can in the original report.)

From http://www.chkrootkit.org/README:

"not tested": the test was not performed -- this could happen in the following situations:
a) the test is OS specific;
b) the test depends on an external program that is not available;
c) some specific command line options are given. (e.g. -r ).

Assuming you did not pass a specific command line option I am going to guess this is "OS specific" in some way.

I would file a bug report with Ubuntu.

  • Which package should I file the bug report under? – user364819 Apr 3 '15 at 16:01
  • 3
    Would syslogd be connected to systemd, though? systemd uses journald, and the problem would be with rsyslogd, right? – muru Apr 3 '15 at 16:02
  • 1
    I would file a bug with chkrootkit – Panther Apr 3 '15 at 16:07

I wrote the chkrootkit authors about it doing a check on syslogd and not on syslogd, present in Ubuntu based distros.

Here's the relevant part of the conversation:

--- snip ---

I understand that it is exclusively a Ubuntu based distribution issue, but is it at all possible that rsyslog may eventually become a target?

Yes, all linux binaries are possible to be infected (rsyslogd included), but to check it I need to see the binary infected. After 20 years since chkrootkit was created I’ve never see a rsyslogd infected. --- snip ---

So it's not a bug.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy