Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
/var/run/udev.pid'. Possible rootkit: xorddos component
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
C5ace
Guru
Guru


Joined: 23 Dec 2013
Posts: 365
Location: Brisbane, Australia

PostPosted: Mon Apr 15, 2019 12:13 am    Post subject: /var/run/udev.pid'. Possible rootkit: xorddos component Reply with quote

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 python, perl, C++, C#, Rust and the likes.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6778

PostPosted: Mon Apr 15, 2019 12:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 2480
Location: Frankfurt, Germany

PostPosted: Mon Apr 15, 2019 1:10 am    Post subject: Reply with quote

'/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:
Code:
file:/var/run/udev.pid:xorddos component
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6778

PostPosted: Mon Apr 15, 2019 11:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 906

PostPosted: Mon Apr 15, 2019 12:14 pm    Post subject: Reply with quote

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

Code:

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16178

PostPosted: Tue Apr 16, 2019 1:52 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 906

PostPosted: Tue Apr 16, 2019 12:20 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6778

PostPosted: Tue Apr 16, 2019 11:00 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 906

PostPosted: Wed Apr 17, 2019 10:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
C5ace
Guru
Guru


Joined: 23 Dec 2013
Posts: 365
Location: Brisbane, Australia

PostPosted: Mon Apr 22, 2019 8:16 am    Post subject: Reply with quote

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

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:
Code:

[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:
Code:

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.
_________________
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 python, perl, C++, C#, Rust and the likes.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16178

PostPosted: Tue Apr 23, 2019 2:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum