This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rootkits and hidden processes


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]