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, prmari...@gmail.com 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: scientific-linux-users@fnal.gov
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.
