Re: systemd rootkit signature?
On Sat, Nov 8, 2014 at 8:03 PM, Jonathan de Boyne Pollard
<J.deBoynePollard-newsgroups@ntlworld.com> wrote:
> Psst!
No need to whisper dramatically.
> Listmaster!
No need to disturb the listmaster, I'm sure.
The list members, maybe:
*** HEY LIST!! ***
THIS IS NOT EVIDENCE THAT SYSTEMD IS AN EVIL MALWARE VECTOR!
That better?
> This was a false positive.
And all two of the participants in this thread acknowledged that probability.
But if I had hit the warning, I'd look for proof, just to be safe and
to be sure I'd not hit a man in the middle.
(Man in the middle being basically the only way such an attack could
be pulled off.)
If I can put a jessie/systemd system together, I'd be curious enough
to load checkrootkit and look for all the false positives, this one in
particular. Until then, maybe you'd care to more specific?
Specifically, it would be nice for you to assert that you've actually
(1) installed checkrootkit and got the warning on a known-good system, and
(2) then modified a copy of the binary (making it inoperable of
course, which is why you do it to a copy) to remove the editing of the
HOME environment variable, and
(3) ascertained that the warning went away.
> M. Ullrich has actually hit
> a genuine, and widely reported, bug in checkrootkit. Ironically, that's a
> false positive too.
>
> Hans Ullrich:
>>
>> Searching for Suckitrootkit... Warning:
>
>> /sbin/init INFECTED
>>
>> The file "/sbin/init" is a symlink to "/lib/systemd/systemd", that
>> means, that systemd is infected.
>
> No it does not. It means that checkrootkit's test for the Suckit rootkit is
> extremely simplistic to the point of being downright incorrect. If you
> look, you'll find that it's looking for the string "HOME" in the binary, and
> that's it. systemd sets various environment variables when it starts
> services, and HOME is one of them. (See the list on the systemd.exec(5)
> manual page.) So it quite legitimately has the string "HOME" in the program
> file image found at "/sbin/init" and matches the erroneous test.
For what it's worth, my memory of checkrootkit (I installed it when I
was using Fedora some years ago, never took it seriously.) is that it
would have throw a warning simply about something like init being a
link instead of an actually executable.
It's looking for theoretically suspicious behaviors. It generates a
lot of warnings, by design. Users of the package are supposed to have
an idea of whether the things it warns about are real issues or not.
> If you
> have any contact with the developers of checkrootkit, you might want to make
> them aware that this bug has hit two init programs (system and upstart both
> have the string "HOME" in their program images, because they both do this.)
> and has spawned quite a lot of bug reports over at least four years with no
> apparent fix to checkrootkit. Here are some:
>
> * https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/676376
> * https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/454566
> * https://bugzilla.novell.com/show_bug.cgi?id=731281
> * https://bugzilla.redhat.com/show_bug.cgi?id=636231
> * https://bugzilla.redhat.com/show_bug.cgi?id=743696
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740898
Contrary to what I said further up in the thread, my guess is that the
only way to fix those kinds of bugs is to set up a built-in,
pre-configured white-list, and a built-in, pre-configured white-list
might constitute a vulnerability, according to their design.
So I'm not sure if it should be reported as a bug or not.
Maybe a documentation bug?
--
Joel Rees
Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.
Reply to: