Very simple.

This rootkit works in user space by coopting glib. The new versions tell the 
user what the rootkit wants it to use. It creates a new user. This user has an 
exception to the /etc/passwd etc rewrites on the way to the application from the 
disk. The files involved do not show up in file requests.

Since the rootkit is in user space files that are statically linked with all the 
user space libraries will be unaffected. Note that rpm is not such a file. So it 
gets told what the modified glibc tells it. How can it detect the rootkit with 
that happening?

I simply mentioned chkrootkit as an example of a tool that would not be able to 
do its job properly unless it was statically linked. I was not advocating it. I 
just want to see if there is a real way around this infection.

The readonly mount option is not suitable in the face of updates. And SELinux, 
if it is full on, should prevent this problem. However, I have yet to get a 
fully configured machine that does not throw SELinux problems. Fully configured 
in this context means local DNS service, local DHCP service for dozens of 
devices, ntp service, samba running with user directories available, 
spamassassin running, very restricted smtp, and little else. By the time I get 
through Samba, DNS, and DHCP I am getting occasional SELinux problems with 
rather spurious seeming troubleshooting reports. It appears, at the moment, 7.2 
may be a little nicer in this regard than 6.8 and 6.8 is nicer than earlier 
versions of 6.

One thing that kills me on this "new" rootkit is that I first ran across it in 
the late 80s on Commodore Amigas. And it is STILL not completely addressed, or 
so it appears.

{o.o}   Joanne


On 2016-09-07 18:22, [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.
>>
>