search

mncoppola / suterusu

An LKM rootkit targeting Linux 2.6/3.x on x86(_64), and ARM
MIT License
635 stars 210 forks source link

Add support for CentOS 6.5 #5

Closed citypw closed 10 years ago

citypw commented 10 years ago

It seems kallsyms_lookup* series are no longer exported on CentOS 6.5 with kernel 2.6.32-431. I added some code to make this rk work on CentOS 6.5 -- 2.6.32-431.el6.x86_64

mncoppola commented 10 years ago

Hey, sorry for the delay. I am at Defcon at the moment and will get to this soon.

citypw commented 10 years ago

Never too late! There must be fun at Defcon. I should go there in the future;-)

I've commit two features: 1, Try to support CentOS 6.5 kernel. 2, Created a directory "test", and write a program that can trigger the ICMP features of Suru.

mncoppola commented 10 years ago

This is a really interesting problem. I did some searching through the Linux kernel commit history and found exactly why kallsyms_lookup_name() is not exported.

This commit initially removes the export: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=3a872d89baae821a0f6e2c1055d4b47650661137

This commit replaces it: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f60d24d2ad04977b0bd9e3eb35dba2d2fa569af9

$ git tag --contains 3a872d89baae821a0f6e2c1055d4b47650661137 | head -n1 v2.6.19 $ git tag --contains f60d24d2ad04977b0bd9e3eb35dba2d2fa569af9 | head -n1 v2.6.33

...which is why we can still use it on modern kernels. CentOS 6.5 is based on 2.6.32, which means it falls within this window. CentOS 7.0 is based on 3.10 which doesn't have this issue.

I wanted to instead use other exported helper functions like kallsyms_on_each_symbol(), but it seems like those also lose (and regain) their export at some point as well.

I appreciate all of the code you've written, but opening a pseudo-file from kernel-land and then string parsing each line is probably not the most elegant solution. Instead, the function sprint_symbol() (also in kallsyms.c) seems to be consistently exported through all versions, which may be a possible solution. We could just call that function and string parse a single line regardless of version. It's not super great but is a better option and is much more stable.

Alternatively, we could just remove all uses of get_symbol() in the first place and avoid the entire problem altogether. The only use of get_symbol() in Suterusu seems to be resolving modules_disabled. The only reference to modules_disabled in the kernel seems to be in kern_table[] for sysctl initialization stuff, which is also not exported. We might be able to walk the entirety of whatever necessary to find it, but I don't really want to figure that out right now.

I'll rewrite the get_symbol() stuff and get it committed soon.

mncoppola commented 10 years ago

On second look, sprint_symbol() is not introduced until http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=42e380832a6911c8a3173ee0172fbc0e4864d80b (v2.6.22)

That means even if we switch off between kallsyms_lookup_name() and sprint_symbol(), there's still a window between v2.6.19 and v2.6.22 that we have no exported symbol resolution options at all.

I'm open to suggestions.

citypw commented 10 years ago

sprint_symbol() seems a good idea. The majority servers dones't use 2.6.18( wasx a stable tree) anymore, so it'd be fine with sprint_symbo() only support until v2.6.22. My suggestion is forget the code before v2.6.22. What do u say?

mncoppola commented 10 years ago

The patch to block module loading was only introduced in v2.6.31 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d43321b7015387cfebbe26436d0e9d299162ea1

...so it might just be a non-issue to not support symbol resolution before then.

I hate ifdef'ng against kernel version but for now I'll just implement a check for v2.6.31 and disable all of the module loading and symbol resolution code before then.