Updated: November 25, 2015
This is the second article in my rather unexpected chkrootkit series. The first one, published roughly four years ago, discussed a problem that is similar to the one we have today. For some reason, probably because you are a Windows user and you can’t help it, you decided to install a couple of rootkit scanner tools in Linux, named chkrootkit and rkhunter. You ran them, and you got an error.
The alarming message displayed by chkrootkit reads: Searching for Suckit rootkit… Warning: /sbin/init INFECTED. This does not sound good, especially since init is sort of a big daddy in your Linux. What now? You read this article to get a better understanding of how to interpret these kind of messages, as well as how to approach the Linux security question.
As I’ve briefly outlined above, you run chkrootkit, and you get the message informing you your system has been infected. In a nutshell, this is your problem. Now, we need to figure out how to fix it. And by fixing it, it could be that we need to understand IF we have a problem in the first place, and how to handle possible false alarms.
Searching for Romanian rootkit… nothing found
Searching for Suckit rootkit… Warning: /sbin/init INFECTED
Searching for Volc rootkit… nothing found
Searching for Gold2 rootkit… nothing found
There are three things you need to do. The very first one is, you need to read my previous article, as it outlines basic forensics and troubleshooting, how to work with Linux kernel modules, how to inspect your processes, your network, your system, etc.
After you’ve done some homework, the second step is ask yourselves, why did you run chkrootkit in the first place? What is the reason for you to suspect that you may have an infection? In my case, as a software reviewer and a tinkerer, it is very important to try and test everything. But if you are just a casual user, what is your motivation? You just cannot linearly translate the Windows security problem to Linux, especially since it’s not a big one in Windows, either. Even so, the 1:1 application of how problems start and end does not apply here.
The third piece is, all right so you’ve run chkrootkit, what about rootkit hunter (rkhunter)? After all, you’ve executed one program, you might as well run both of them. This will help you narrow down your anxiety. If both tools report the same issue, you might need to investigate more, but if only one does, it increases the chance of this message being a false positive. Indeed, if you run rootkit hunter, you most likely won’t get anything:
The next step is to reboot and perform the chkrootkit scan again. Why, you’d ask? Well, if your system is in some kind of inconsistent state, for whatever reason, tools scanning its memory space might get confused. A reboot will help in this regard, and in the worst case, it won’t get rid of any rogue kernel modules. So you have nothing to lose, except your dignity for rebooting a Linux box. After restart, a second run with chkrootkit hunter will probably reveal nothing.
Why? What gives?
So you might be wondering what happened? Well, tools designed to inspect the virtual memory space need to be as slick as debuggers, and this isn’t done easily. Lots of errors can happen. For instance, if you had a system update and have not rebooted, the init binary may have changed, and not match the one in memory. Or there might be other changes on your disk that could trigger a false positive.
If you do a bit of Internet soul searching, you will find a bug dating back to 2009, and another reference from AskUbuntu from 2011, both touching the same topic. As you can imagine, it has not been really fixed. However, it also means you don’t really have any problem, or a very reliable tool for examining your system. Still, problem solved.
Here’s the end of another howto, so to speak, but hopefully it does give you what you need. Mostly, some extra understanding how Linux security works. In other words, the scanners are not what you need to focus on, and there are many other ways to keep your system in the right shape as well as detect problems.
Secondly, if you do encounter issues with Linux scanners, should you deploy them, then there are ways of doing it proper like. Run multiple scans with reboots in between, try different tools, compare the results. Consistency is the key factor, and if you can’t find a common result, then you’re probably dealing with errors in human engineering. Still, our problem is solved, and you can go back to enjoying whatever you were doing before you suddenly decided to run chkrootkit, and then ended up here.