[gentoo-user] rkhunter reports xorddos component

Mick

unread,

Feb 27, 2019, 7:30:03 AM2/27/19

to

I noticed this beauty popping up a day ago:

Rootkit checks...
Rootkits checked : 498
Possible rootkits: 1
Rootkit names : xorddos component

Fair enough the log reported a suspect file:

====================================
Checking for file '/var/run/sftp.pid' [ Not found ]
Checking for file '/var/run/udev.pid' [ Warning ] <==This one
Checking for file '/var/run/mount.pid' [ Not found ]
[snip ...]

Warning: Checking for possible rootkit files and directories [ Warning ]
Found file '/var/run/udev.pid'. Possible rootkit: xorddos component

===================================================================

I think it is a false positive, because none of the files mentioned in the
interwebs[1] are seen lurking in my system, but I thought it wiser to check
further.

[1] http://hackermedicine.com/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/

The rkhunter report of this xorddos component seems to have arrived with:

sys-fs/udev-init-scripts-33

or

sys-apps/dbus-1.12.12-r1

Could it be these versions are now launching /run/udev.pid? Is a file /run/
udev.pid present in your system?

In any case, the file merely contains the PID number of /lib/systemd/systemd-
udevd, rather than an ELF binary and /etc/init.d/ does not contain anything
suspicious. However, with armies generating variants of every conceivable
malware I don't know if it pays to be a bit paranoid about this.

--
Regards,
Mick

signature.asc

Peter Humphrey

unread,

Feb 27, 2019, 8:50:03 AM2/27/19

to

Yes, I have such a text file, containing just a PID.

> In any case, the file merely contains the PID number of
> /lib/systemd/systemd- udevd, rather than an ELF binary and /etc/init.d/
> does not contain anything suspicious. However, with armies generating
> variants of every conceivable malware I don't know if it pays to be a bit
> paranoid about this.

They really are out to get us...

--
Regards,
Peter.

Dale

unread,

Feb 27, 2019, 9:00:03 AM2/27/19

to

Little info here. I don't run systemd here but I also have that file.
I checked with equery b but obviously nothing owns it since it is a pid
file generated when udev or something starts. This is my versions of
udev, dbus and other friends:

root@fireball / # equery list *udev* dbus
* Searching for *udev* ...
[IP-] [ ] dev-libs/libgudev-232:0/0
[IP-] [ ] sys-fs/eudev-3.2.5:0
[IP-] [ ] sys-fs/udev-init-scripts-33:0
[IP-] [ ] virtual/libgudev-232:0/0
[IP-] [ ] virtual/libudev-232:0/1
[IP-] [ ] virtual/udev-217:0

* Searching for dbus ...
[IP-] [ ] sys-apps/dbus-1.10.24:0
root@fireball / #

Like you, I sort of suspect a false positive but I don't know nearly
enough to know for sure it is either. Maybe someone else can chime in
and give more ideas. If enough people say they have it, then either
someone is doing some coding on a very low level or it is a false
positive. Let's hope for the later.

Dale

:-) :-)

Rich Freeman

unread,

Feb 27, 2019, 9:40:02 AM2/27/19

to

If it really looks like a PID file I'd assume that this is a false
positive. It would likely be generated by openrc and the init.d
script. Since almost no other distros use OpenRC it isn't entirely
surprising that a tool like rkhunter wasn't tested using it to catch
the false positive. I'd report the issue to them.

If by "they" you meant systemd I don't really see how they're actually
involved. Well, other than indirectly by virtue of not creating this
file and being the only config the rkhunter maintainers are probably
using.

Keep in mind that by its nature rkhunter is going to be a bit limited,
at least when used in this way. If it supports offline scanning (ie
from a rescue disk) then that would be pretty secure, but if it is
running on a potentially-compromised kernel then a clever rootkit
could evade it. Just the usual cat-and-mouse game with these sorts of
things, but rkhunter can only see the filesystem and process tree that
the potentially-compromised kernel lets it see. Offline scanning
tools are always going to be superior in this regard, if you have
known-clean (ideally read-only) boot media, and a clean firmware to
boot it from. Really the cleanest solution would be to remove the
hard drives and scan them on a separate machine.

--
Rich

Mick

unread,

Feb 27, 2019, 10:10:03 AM2/27/19

to

Thanks for this. At least I know it is not just me and mine.

> > In any case, the file merely contains the PID number of
> > /lib/systemd/systemd- udevd, rather than an ELF binary and /etc/init.d/
> > does not contain anything suspicious. However, with armies generating
> > variants of every conceivable malware I don't know if it pays to be a bit
> > paranoid about this.
>
> They really are out to get us...

:-)

--
Regards,
Mick

signature.asc

Mick

unread,

Feb 27, 2019, 10:10:03 AM2/27/19

to

On Wednesday, 27 February 2019 13:50:58 GMT Dale wrote:

> Little info here. I don't run systemd here but I also have that file.

I checked on a non-gentoo systemd based distro and this file is not there. It
seems it is related to sys-fs/udev-init-scripts.

> I checked with equery b but obviously nothing owns it since it is a pid
> file generated when udev or something starts. This is my versions of
> udev, dbus and other friends:
>
>
> root@fireball / # equery list *udev* dbus
> * Searching for *udev* ...
> [IP-] [ ] dev-libs/libgudev-232:0/0
> [IP-] [ ] sys-fs/eudev-3.2.5:0
> [IP-] [ ] sys-fs/udev-init-scripts-33:0
> [IP-] [ ] virtual/libgudev-232:0/0
> [IP-] [ ] virtual/libudev-232:0/1
> [IP-] [ ] virtual/udev-217:0
>
> * Searching for dbus ...
> [IP-] [ ] sys-apps/dbus-1.10.24:0
> root@fireball / #

My versions are more recent than yours, although sys-fs/udev-init-scripts-33:0
are the same. I think this is what's bringing this PID file in /run/.

False positive me thinks, which is not a first for rkhunter.

Thanks Dale for letting me know.
--
Regards,
Mick

signature.asc

Mick

unread,

Feb 27, 2019, 10:20:02 AM2/27/19

to

On Wednesday, 27 February 2019 14:29:40 GMT Rich Freeman wrote:
> On Wed, Feb 27, 2019 at 8:47 AM Peter Humphrey <pe...@prh.myzen.co.uk>
wrote:
> > On Wednesday, 27 February 2019 12:27:59 GMT Mick wrote:
> > > Could it be these versions are now launching /run/udev.pid? Is a file
> > > /run/ udev.pid present in your system?
> >
> > Yes, I have such a text file, containing just a PID.
> >
> > > In any case, the file merely contains the PID number of
> > > /lib/systemd/systemd- udevd, rather than an ELF binary and /etc/init.d/
> > > does not contain anything suspicious. However, with armies generating
> > > variants of every conceivable malware I don't know if it pays to be a
> > > bit
> > > paranoid about this.
> >
> > They really are out to get us...
>
> If it really looks like a PID file I'd assume that this is a false
> positive.

Yes.

> It would likely be generated by openrc and the init.d script.

Yes.

> Since almost no other distros use OpenRC it isn't entirely
> surprising that a tool like rkhunter wasn't tested using it to catch
> the false positive. I'd report the issue to them.

Well, if the offending file were a binary the warning would still be valid -
so worth investigating anyway.

> If by "they" you meant systemd I don't really see how they're actually
> involved. Well, other than indirectly by virtue of not creating this
> file and being the only config the rkhunter maintainers are probably
> using.

I think Peter was reinforcing my statement. 'They' know who they are, so
better left at that. LOL!

> Keep in mind that by its nature rkhunter is going to be a bit limited,
> at least when used in this way. If it supports offline scanning (ie
> from a rescue disk) then that would be pretty secure, but if it is
> running on a potentially-compromised kernel then a clever rootkit
> could evade it. Just the usual cat-and-mouse game with these sorts of
> things, but rkhunter can only see the filesystem and process tree that
> the potentially-compromised kernel lets it see. Offline scanning
> tools are always going to be superior in this regard, if you have
> known-clean (ideally read-only) boot media, and a clean firmware to
> boot it from. Really the cleanest solution would be to remove the
> hard drives and scan them on a separate machine.

I ran it offline too and investigated the fs and its contents at the same
time, but still didn't find anything suspicious. rkhunter often comes up with
false positives or issues warnings about innocuous files. It is not some
superior diagnostic tool, but nevertheless made me pay attention. Better be
safe than sorry with these matters.

--
Regards,
Mick

signature.asc

Dale

unread,

Feb 27, 2019, 11:00:03 AM2/27/19

to

Mick wrote:
> On Wednesday, 27 February 2019 13:50:58 GMT Dale wrote:
>
>> Little info here. I don't run systemd here but I also have that file.
> I checked on a non-gentoo systemd based distro and this file is not there. It
> seems it is related to sys-fs/udev-init-scripts.

I mentioned that so that systemd can be eliminated as a cause. It has
to be related to something besides that. Most likely, the udev thingy.
lol

>
>> I checked with equery b but obviously nothing owns it since it is a pid
>> file generated when udev or something starts. This is my versions of
>> udev, dbus and other friends:
>>
>>
>> root@fireball / # equery list *udev* dbus
>> * Searching for *udev* ...
>> [IP-] [ ] dev-libs/libgudev-232:0/0
>> [IP-] [ ] sys-fs/eudev-3.2.5:0
>> [IP-] [ ] sys-fs/udev-init-scripts-33:0
>> [IP-] [ ] virtual/libgudev-232:0/0
>> [IP-] [ ] virtual/libudev-232:0/1
>> [IP-] [ ] virtual/udev-217:0
>>
>> * Searching for dbus ...
>> [IP-] [ ] sys-apps/dbus-1.10.24:0
>> root@fireball / #
> My versions are more recent than yours, although sys-fs/udev-init-scripts-33:0
> are the same. I think this is what's bringing this PID file in /run/.
>
> False positive me thinks, which is not a first for rkhunter.
>
> Thanks Dale for letting me know.

More than happy to help. We compare enough, we'll get to the bottom of
it eventually.

Dale

:-) :-)

Neil Bothwick

unread,

Feb 27, 2019, 1:00:04 PM2/27/19

to

On Wed, 27 Feb 2019 15:07:35 +0000, Mick wrote:

> > Little info here. I don't run systemd here but I also have that
> > file.
>
> I checked on a non-gentoo systemd based distro and this file is not
> there. It seems it is related to sys-fs/udev-init-scripts.
>

Indeed, I am getting this warning on one openrc machine and none of the
systemd ones. Another openrc system does not have it, but that has not
been rebooted since updating sys-fs/udev-init-scripts.

--
Neil Bothwick

NOTICE:
-- THE ELEVATORS WILL BE OUT OF ORDER TODAY --
(The nearest working elevators are in the building
across the street.)

Philip Webb

unread,

Feb 27, 2019, 2:10:03 PM2/27/19

to

190227 Neil Bothwick wrote:
> On Wed, 27 Feb 2019 15:07:35 +0000, Mick wrote:
>> I checked on a non-gentoo systemd based distro and this file is not there.
>> It seems it is related to sys-fs/udev-init-scripts.
> Indeed, I am getting this warning on one openrc machine
> and none of the systemd ones. Another openrc system does not have it,
> but that has not been rebooted since updating sys-fs/udev-init-scripts.

On my Openrc system, I have /run/udev.pid ,
which contains the PID of /sbin/udev.d , started at the latest reboot.
My machine is a simple home desktop, unlikely to be subverted somehow.
As someone suggested, Rkhunter is probably tested only on Systemd machines.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca