Kextstat_ASLR util or how to start hiding your kernel rootkit in Mountain Lion

Welcome back!

This is a small post about a quick util that I created yesterday’s night while working on a side project. Mountain Lion introduced kernel ASLR and the kextstat util output doesn’t support (yet?) this feature. The addresses are not the real ones and this is quite annoying (kgmacros from kernel debugging also seem to fail at this!).

What this util does is to read the kernel extensions information via the /dev/kmem device (hence this util is probably not useful for a large audience) and display it like kextstat does with the correct address for each kext (just the most important information, the linked against info might be added in the future).

Besides useful for anyone wanting to read the kexts information, it’s also useful for rootkits because it implements the trick that Crisis uses to retrieve this information for 64bits kernels (my posts were against the 32bits version). The only piece left is how to find the sLoadedKexts symbol. Here it’s hardcoded for version 10.8.2. I do have a nice trick to find it but it’s not ready for public consumption. First I want to see if it’s possible to implement my new idea :-)

Due to some whacky reason I was convinced that each kernel extension had individual ASLR slide values, which after I got this util working was demonstrated false. The slide is the same as the kernel. I probably had some mistake while searching manually for the kexts. Practice makes perfection and part of this code was needed for my new project so it’s not wasted time!

The code is located at https://github.com/gdbinit/kextstat_aslr.
One feature to be added is to “bruteforce” the whole sLoadedKexts array. The reason is that rootkits usually decrease the count but the information remains there. Since the class has a capacity instance variable, we can move beyond the count and check if there’s anything suspicious there. Just a fun detail :-)

The last detail is that this is susceptible to changes to OSArray and OSKext classes since it’s using offsets into the instance variables. The best way would be to get this ported to C++ but I still have to read a book or two on C++. Need to verify how stable are these classes since Snow Leopard.

Phew, too many written words for such small util!
Have fun,

fG!

Update:
There is a privileged syscall called kas_info() that allows to retrieve kernel ASLR value. I’ve updated the code to use this feature.

5 thoughts on “Kextstat_ASLR util or how to start hiding your kernel rootkit in Mountain Lion

  1. You did it again = ) and I learned a lot again !!!
    Do you have any plan to give a presentation on the conference??
    I want to attend your presentation = )

    1. Always great to hear someone learning new things :-)
      I don’t have plans to present anything in the short time. Trying to write something for Phrack!

  2. Great post! I learned a lot from it.
    One question, I know sLoadedKexts can be very useful for rootkit, but wouldn’t it be easier to use libkern APIs just for kextstat-like outputs?

    1. Hi!
      I hate and suck at C++ so IOKit is not my thing.
      Are you talking about libkern having APIs for this or just because of it being IOKit so easier to deal with the class?
      Thi was more of a PoC because it has hardcoded addresses. Recompiling XNU breaks it.
      Need to improve it one of htese days to not require any manual addresses.
      fG!

      1. It’s OSKextCopyLoadedKextInfo. Jonathan Levin talks about it in chapter 18 of OS X and iOS internal. Not 100% sure about what the returned CFDictionaryRef will be if rootkit decreases the count, but I guess it won’t contain anything beyond the count.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>