Is the part of the filesystem which handles links in kernel space or user space? 
That would make a great deal of difference as this rootkit tool evolves. At the 
moment it appears it is "contagious", meaning Linux installs can become 
infected. Since the files that are infected are shared system library files it 
suggests at least one route into root level privileges to make the install. 
After that you have a root level user who does not appear in conventional checks 
on /etc/passwd and directory listings. There is nothing that says this tool 
cannot evolve more self-protection capabilities and still remain hiding in user 
space, where it would normally not be expected to hang out. This would get 
around some of the new secure BIOS protections that exist. It can keep the 
original files around and let checksum utilities read it instead of the modified 
files.

I figure with all malware the best thing to do is not catch it, use "safe 
computing" with condoms like SELinux enabled and screwed down even tighter than 
RHEL out of the box. I'm mostly musing about how it could be made more likely 
for "the usual tools" to discover the hacking. (And as noted I am bemused 
because this resembles several pieces of old Amiga malware.)

{^_^}   Joanne

On 2016-09-07 19:03, Steven J. Yellin wrote:
>     Are rpm and the check sum tools statically linked?  If not, hiding copies of
> them might not help if libraries have been compromised.  But busybox is
> statically linked, and it looks like it can be easily used to replace most
> commands used to check security without going to the trouble of pulling files
> from it.  For example, 'ln -s busybox md5sum' allows use of busybox's md5sum and
> 'ln -s busybox vi' allows use of its vi. See
> https://busybox.net/FAQ.html#getting_started .
>
> Steven Yellin
>
> On Wed, 7 Sep 2016, [log in to unmask] wrote:
>
>> Jdow,
>>
>> Why are you looking at thatÿÿ for root kit prevention? It's a very old fashion
>> approach, I would use the RPM's verify  command or one of the many filesystem
>>  check sum tools available for that instead. Either one can tell you if ÿÿany
>> critical binaries or libraries have been compromised very easily and there are
>> even tools built around them to do it on a network wide level. Further more if
>> you really want to make your systems resistant to root kits, readonly mount of
>> / and /usrÿÿ is still your best bet, even Red Hat products like RHEV use that
>> method on appliances.
>>
>>
>>   Original Message
>> From: jdow
>> Sent: Wednesday, September 7, 2016 19:09
>> To: [log in to unmask]
>> Subject: Re: Re: Regarding latest Linux level 3 rootkits
>>
>> Thanks Vladimir,
>>
>> I suppose I could pull the necessary files from busybox as a means of keeping a
>> more generic Linux system in security trim. This might be a useful tool set to
>> suggest upstream. A statically linked less would allow a quick check for the
>> hidden user. A statically linked chkrootkit would find the bad file size for the
>> affected glib libraries.
>>
>> {^_^} Joanne
>>
>> On 2016-09-07 03:36, Vladimir Mosgalin wrote:
>>> Hi jdow!
>>> ÿÿ
>>> On 2016.09.06 at 23:15:04 -0700, jdow wrote next:
>>>
>>>> Is there any source for a VI, VIM, or even EMACS that has all libraries
>>>> compiled into it statically? That would make monitoring for the rootkit much
>>>> easier. The same could be said for utilities such as chkrootkit. With
>>>> compiled in static libraries these level three (user space) rootkits can't
>>>> edit the results you get, as easily. (Any file system components in user
>>>> space would also have to be statically linked.)
>>>
>>> Busybox would work. It's usually build statically (either that, or it's
>>> easy to make that kind of build) and includes vi clone. Very poor man's
>>> vi, just like other busybox utilities, but nevertheless. Current version
>>> supports some neat stuff like autoindent and undo.
>>>
>>