False positive `chkrootkit` on `slib.sh` file

Hello everyone, I installed chkrootkit for detection on the new ubuntu server & just install on the ubuntu server virtualmin, but when I ran chkrootkit it is displayed this error:

Searching for Linux.Xor.DDoS ... INFECTED: Possible Malicious Linux.Xor.DDoS installed
/tmp/.virtualminxxx/files/slib.sh

Is it a false postive alert, dont no need to scare of ? or it is a real rootkit?
Thank you

Is there really a file named slib.h? Our shell library for the installer is named slib.sh.

Our script slib.sh is definitely not a root kit. (You can see the source here: slib/slib.sh at master · virtualmin/slib · GitHub)

I don’t know why chkrootikit would consider this a trojan. But, if Virtualmin has been installed successfully, that tmp dir can be deleted (I think we delete it automatically on successful install, but maybe I’m wrong about that…I’ll check). And, /tmp is automatically deleted on reboots in the general case.

yes it is /tmp/.virtualmin-5241/files/slib.sh displayed as infected.
yes virtualmin was successfully installed but I don’t if I can delete this file, otherwise I’m waiting for any feedbacks from you.
Thank you

No. slib.h should not exist. Our file is called slib.sh.

Is there actually a file named slib.h? If so, our installer did not create it, and I wouldn’t know where it came from or how it got there.

nn it is .sh I just wrote wrong
I do apologize, but when I do reboot now it is gone. if it is disappeared when I made the reboot, what does mean?
Thank you

It means exactly what I said. /tmp is deleted automatically on reboots in the usual configuration of most Linux systems.

so, if it was a rootkit it will not be deleted from the tmp even we did a reboot , right?

If it was a root kit, it would have hidden itself and you’d never know it existed (and still exists). If an attacker has root, you may never know they were there, until you start getting abuse reports about your IP from your provider, because they can modify the tools chkrootkit uses to detect rootkits. Unless you run the scan when booted from a readonly filesystem (e.g. a rescue CD ISO), you have no way of knowing whether something is hiding on the system.

I’m surprised chkrootkit flagged one of our files, especially since our file is not even named the same as what it thinks is an indicator of an exploit.

I believe it to be a false positive, but since you didn’t compare our slib.sh to the flagged file before rebooting deleted the file (as I told you it would) you have no way of knowing.

rootkits do not generally setup shop in /tmp, anyway.

And, I cannot download the chkrootkit source from their website, so I can’t check to see what’s going on. But, chkrootkit seems to be kinda unmaintained…so, it’s probably not very relevant to current attacks.

yeah it was a mistake from my side not comparing the two files before I did the reboot, anyway as you said definitely it is a false positive.
Thank you so much for your explanation and your help too.
I do appreciate it.
Thanks a lot

so it is not recommended to install it because it is unmaintained , or just keep it?

I don’t believe it does much useful when run from the same OS install you’re currently running, because a rootkit can hide itself from the tools chkrootkit uses to look for rootkits. I’ve already explained how to make chkrootkit (and similar tools) useful.

If you cannot trust ls, ps, gpg, md5sum, etc. to tell you the truth, you cannot detect when something is amiss. A good rootkit can replace any programs that might reveal its presence to a scanner like chkrootkit. It would have to be a dumb rootkit to leave itself exposed to a well-known rootkit scanning tool.

2 Likes

yes, I totally agree with you if it was rootkit it will not let itself exposed to a well-known rootkit scanning tool like chkrootkit.Thank you so much sir for this explanation I do appreciate it

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.