# /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.

----------

## Ant P.

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

'/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:

```
file:/var/run/udev.pid:xorddos component

```

----------

## Ant P.

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

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

```

SCRIPTWHITELIST=/bin/egrep

SCRIPTWHITELIST=/bin/fgrep

SCRIPTWHITELIST=/usr/bin/ldd

SCRIPTWHITELIST=/usr/bin/whatis

SCRIPTWHITELIST=/usr/bin/lwp-request

ALLOWHIDDENDIR=/dev/.udev

ALLOWDEVFILE=/dev/shm/sem.ADBE_*

ALLOWDEVFILE=/dev/shm/sem.ADBE_WritePrefs_*

ALLOWDEVFILE=/dev/shm/sem.ADBE_ReadPrefs_*

XINETD_ALLOWED_SVC=/etc/xinetd.d/cups

PWDLESS_ACCOUNTS="guest"

USER_FILEPROP_FILES_DIRS=/etc/init.d/hdparm

USER_FILEPROP_FILES_DIRS=/etc/init.d/pciparm

USER_FILEPROP_FILES_DIRS=/etc/init.d/net.lo

RTKT_FILE_WHITELIST=/etc/init.d/hdparm

RTKT_FILE_WHITELIST=/etc/init.d/pciparm

RTKT_FILE_WHITELIST=/etc/init.d/net.lo

RTKT_FILE_WHITELIST=/var/run/udev.pid

SCRIPTWHITELIST=/etc/init.d/hdparm

SCRIPTWHITELIST=/etc/init.d/pciparm

SCRIPTWHITELIST=/etc/init.d/net.lo

ALLOWPROCDELFILE="/usr/lib/openoffice/program/soffice.bin"

ALLOWPROCDELFILE="/usr/libexec/dovecot/imap"

ALLOWPROCDELFILE="/usr/libexec/dovecot/imap-login"

ALLOWPROCDELFILE="/usr/sbin/dovecot"

ALLOWPROCLISTEN=/usr/sbin/knockd

```

I added each line AFTER rkhunter flagged the file or process as potential trouble, and after satisfying myself the file is what I expect.

rkhunter isn't trying to push you to systemd.  It was built over time, based on observed characteristics of known system exploits.  Although I suppose one could find that systemd is itself a system exploit.

----------

## Hu

 *cboldt wrote:*   

> rkhunter isn't trying to push you to systemd.  It was built over time, based on observed characteristics of known system exploits.

 Ant P.'s point was that this file is perfectly reasonable to have on non-infected systems that use a freestanding udev, which is still a fairly common configuration.  If the tool warns on the mere presence of the file, independent of content, it will raise a false positive on every such system.  That is at best irresponsible and at worst suggests the rkhunter author is trying to cause angst.  It should have contained some additional logic to avoid flagging standard pid files, and instead only warn when that file has been repurposed for malicious storage.

----------

## cboldt

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.

 *cboldt wrote:*   

> 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.

 

Unfortunately there's no way to link to a forum search query directly here, but if there's any doubt: just put "rkhunter" into that box at the top right - it creates nothing but support burden from people who see false positives like this and freak out over it. Not a single legitimate catch to be found.

----------

## cboldt

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

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

```

MAIL-ON-WARNING=webmaster@c5ace.com

COPY_LOG_ON_ERROR=1

ALLOW_SSH_ROOT_USER=yes 

SCRIPTWHITELIST=/bin/egrep

SCRIPTWHITELIST=/bin/fgrep

SCRIPTWHITELIST=/usr/bin/ldd

SCRIPTWHITELIST=/usr/bin/lwp-request

ALLOWDEVFILE=/dev/mdev.seq

ALLOWIPCPROC=/usr/bin/xfdesktop

ALLOWIPCPROC=/usr/bin/xfce4-terminal

ALLOWIPCPROC=/usr/lib64/firefox/firefox

ALLOWIPCPROC=/usr/lib64/thunderbird/thunderbird

RTKT_FILE_WHITELIST=/var/run/udev.pid

# DISABLE_TESTS=suspscan hidden_ports hidden_procs deleted_files packet_cap_apps apps

```

I am still have this warning:

```

[17:54:06] Info: Starting test name 'deleted_files'

[17:54:09]   Checking running processes for deleted files    [ Warning ]

[17:54:09] Warning: The following processes are using deleted files:

[17:54:09]          Process: /usr/bin/python3.6m    PID: 23577    File: /tmp/#1966091

[17:54:09]          Process: /usr/bin/python3.6m    PID: 23645    File: /tmp/#1966092

[17:54:09]
```

Just can't find these files apperenly created by /usr/bin/python3.6m. 

They only appear after "startx".

They result in:

```

Rootkit checks...

    Rootkits checked : 505

    Possible rootkits: 1
```

Maybe somebody has an answer?

By the way, I had in January a "Bill Gates" Trojan on my box running a very old P2P application under Wine. This continuesly spawned hundreds of files and slowed down the box. Rkhunter indicated "Possible rootkits: 1 Bill Gates" or similar. My immediate fix was to 'dd' the hard drive and restore a 2 week old backup of OS.

I received an e-mail a few days later from some idiot asking me to pay $1,000.00 with Bitcoins to restore my data.

----------

## Hu

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.

----------

