[vox-tech] Possible rootkit

[Rick Moen]

Just seeing what insights might be gleaned from this.

Quoting Richard Harke (paleopenguin at gmail.com):

> I may have screwed up. I opened a GIF that I received in an email using
> ImageMagick. 

This implies that you were doing so as your regular userID, not as root
or any other privileged user.

> The image didn't have a close button so I used ps -A to find the task.
> I didn't find any called ImageMagick but there was one named
> display.im6 and when I killed it, the icon on the task bar went away.

So, first thing to consider is:  'What is ImageMagick?'
http://www.imagemagick.org/ says:

  ImageMagick® is a software suite to create, edit, compose, or
  convert bitmap images.

The key word to notice there is 'suite'.  It's not a single program
called 'ImageMagick' (or anything else).  It is a collection of
utilities (and, as it turns out, a programming interface for other
frontends to transparently use those utilties and their related libs).

As mentioned on
http://www.imagemagick.org/script/command-line-tools.php, ones of
ImageMagick's approximately dozen command-line tools is one called
'display'.  That appears to be what you observed in your ps output.

> But I also found a task called rtkit-daemon which I killed.

As you'll have seen from the discussion thread, this process is benign
-- to the extent that any of the bloated, horrific, and constrantly
changing betaware emerging from the Freedesktop.org people is benign.
;->  It's the Realtime Policy and Watchdog Daemon, a D-Bus system
service that changes the scheduling policy of user processes/threads
upon request, permitting the user to impose real-time scheduling on
normal user processes.

We could have a whole separate discussion about whether friends let
friends us Freedesktop.org system software (including GNOME3, D-Bus,
Polkit, etc.).  However, for whatever reason, your system does include
such (ugh) system components.  On the one hand, it's commendable of you
to experiment and find out what processes you actually want to run
through the straightforward and logical expedient of killing them and
seeing if anything you care about breaks.  On the other hand, in my
experience, the noble goal of knowing what processes you run and running
only the processes you want to run becomes so extremely difficult with
the most-complex Desktop Environments (such as GNOME3) that the effort
will soon become impractical (unless you switch to simpler DE software
or to no DE and using just an old-school window manager).

> But now I also find a whole new directory named /run which seems to 
> have a lot of executables in it.

https://wiki.debian.org/ReleaseGoals/RunDirectory

  /run is a new cross-distribution location for the storage of transient
  state files -- that is, files containing run-time information that may
  or may not need to be written early in the boot process and which does
  not require preserving across reboots.

  /run is a tmpfs.

  /run replaces several existing locations described in the Filesystem
  Hierarchy Standard:

  /var/run -> /run
  /var/lock -> /run/lock
  /dev/shm -> /run/shm [currently only Debian plans to do this]
  /tmp -> /run/tmp [optional; currently only Debian plans to offer this]
  /run also replaces some other locations that have been used for
  transient files:

  /lib/init/rw -> /run
  /dev/.* -> /run/*
  /dev/shm/* -> /run/*
  writable files under /etc -> /run/*


> In any case I assume everything in /run is trojaned.

Nope.  Actually, if you look at /run, you'll notice that it's a
root-owned hierarchy.  So, if we take as given your assumption that the
gif that you handed to the ImageMagick 'display' utility was a
devilishly clever misshaped file crafted to convince /usr/bin/display to
do evil things, how would that hypnotised utility escalate privilege to
root authority in order to make modifications in /run?


> I am open for advice.

Best advice I can think of:  Your concern and interest in knowing what's
a legitimate system process is commendable.  Rather than being
embarrassed over the false alarm, consider building on the experience to
deepen your knowledge of your system, which is in the final analysis the
only effective way to distinguish legitimate from illegitimate system
operation.