/var/run/udev.pid'. Possible rootkit: xorddos component

C5ace

Looks like rkhunter considers "udev" a possibe rootkit on my OpenRC system.
Could be a systemd infestation.

[code]rkhunter -c
System checks summary
=====================

File properties checks...
Files checked: 148
Suspect files: 4

Rootkit checks...
Rootkits checked : 505
Possible rootkits: 4
Rootkit names : xorddos component

Applications checks...
Applications checked: 3
Suspect applications: 0

The system checks took: 2 minutes and 38 seconds

All results have been written to the log file: /var/log/rkhunter.log

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)[code]

[code]/var/log/rkhunter.log
.
.
.
[09:28:37] Checking for directory '/usr/share/.sqe' [ Not found ]
[09:28:37] Warning: Checking for possible rootkit files and directories [ Warning ]
[09:28:37] Found file '/var/run/udev.pid'. Possible rootkit: xorddos component
[09:28:37]
[09:28:37] Info: Starting test name 'possible_rkt_strings'
[09:28:37] Performing check for possible rootkit strings
.
.
.[/code]

Please check your OpenRC system.
_________________
Observation after 30 years working with computers:
All software has known and unknown bugs and vulnerabilities. Especially software written in complex, unstable and object oriented languages such as perl, python, C++, C#, Rust and the likes.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Or maybe rkhunter is garbage. I think that's a far more likely explanation than some rootkit miraculously managing to hide itself within a text file containing a 3 digit number.

mike155 · Posted: Mon Apr 15, 2019 1:10 am Post subject:

'/var/run/udev.pid' doesn't exist on Systemd machines.

I looked at the source code of rkhunter. I found the rule below, which will print a warning if the file '/var/run/udev.pid' exists:

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

What kind of heuristic is that? Trying to scare people away from eudev and into the waiting arms of systemd?

Software like this is not a substitute for using one's brain.

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

There are a few files that can be innocuous or part of a rootkit. rkhunter has a way to "ignore" the innocuous ones. I have about 20 lines in /etc/rkhunter.conf.local to deal with this noise. /etc/rkhunter.conf.local is automatically sourced when rkhunter does a --check

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

My point was that rkhunter raises numerous false positives, and always has to the best of my knowledge. Its config file is designed to accommodate exceptions.

I added this particular pidfile exception to /etc/rkhunter.conf.local the day after portage updated sys-fs/udev-init-scripts. That occurred late February 2019. Before the udev-init-scripts update, rkhunter did not throw this particular false positive.

Another point I insinuated was that rkhunter is the product of rootkit examination, not init system examination.

I think your suggestion to look inside the suspicious file before flagging it to the user is well taken, but if rkhunter sucks so bad, better to remove it from circulation.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

Most if not all people setting up rkhunter will get false positives, even if they are setting up on an already-infected system. In my uninfected-system case, initial settup flagged egrep and fgrep, a few /etc/init.d files, and a hidden .udev directory. I'd be shocked to find support questions when a setup "worked without issue," and am not surprised at all that many people will mistakenly fear their system is infected, and seek help/comfort to diagnose and fix.

I suspect this sort of problem is common to all intrusion detection schemes.

At any rate, what prompted me to weigh in was my belief that the author or rkhunter is unlikely using it to steer toward any particular init; that there is no connection between systemd sentiment and rkhunter behavior.

C5ace · Posted: Mon Apr 22, 2019 8:16 am Post subject:

Thanks everyone for the various reccomendations. It's fixed now by adding to to the beginnung of /etc/rkhunter.conf:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23082

You cannot find them because they have been unlinked, but left open. This is a relatively common operation in some programs and is not inherently suspicious. Inspect the command line of the processes flagged by rkhunter to learn what Python script they are executing. Check that script for whether it deletes files that it leaves open.