Re: [gentoo-user] rkhunter reports xorddos component

[Rich Freeman]

On Wed, Feb 27, 2019 at 8:47 AM Peter Humphrey <peter@××××××××××××.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.  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