This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: rootkits and hidden processes
- From: Josh Stone <jistone at redhat dot com>
- To: systemtap at sourceware dot org
- Date: Mon, 21 Oct 2013 11:27:56 -0700
- Subject: Re: rootkits and hidden processes
- Authentication-results: sourceware.org; auth=none
- References: <1555905208 dot 2010315 dot 1382180844427 dot JavaMail dot ngmail at webmail11 dot arcor-online dot net>
On 10/19/2013 04:07 AM, ch2009@arcor.de wrote:
> Dear all,
>
> is it possible to find rootkits with systemtap? How to list all processes?
>
> There's a presentation about systemtap and "rootkits made trivial",
> so finding rootkits shouldn't be too hard!
It's tough to say -- I think you'll be in an arms-race in detecting the
various ways a rootkit can hide itself.
For instance, that presentation only outlines how to hide from the
module list. But it uses kprobes for this, so it will be visible in
{debugfs}/kprobes/list. Thus, the next generation rootkit would be wise
to also hide itself there. And so it continues.
A systemtap rootkit-detector does have the advantage of more direct
access to kernel data. The presentation's module-hiding worked by
hooking m_start/m_stop, which only hides from procfs, but a stap script
could read the modules list at any time.
For listing all processes, I don't think we have any specific support.
Perhaps probe process.begin or process.thread.begin will work for you,
but those only trigger the first time a process/thread actually runs.
If you drop to embedded-C, you can use for_each_process or even
do_each_thread{...}while-each_thread, although those should use
tasklist_lock, which isn't exported. You could cheat that by using a
probe point where that is lock already held, much like the presentation
did for tweaking the module list.