On 10/5/05, Edward Balas <ebalas_at_iu.edu> wrote:
> Thorsten Holz wrote:
>
> >Edward Balas wrote:
> >
> >>Could you elaborate on what you mean by rather hard to hide the
> >>kernel module? I presume you mean beyond simply modifying the kernel
> >>data structure to remove the module from the linked list of modules
> >>which is done currently?
> >
> >
> >I think he means that it is hard to hide a module on a host if the
> >attacker has uid 0. After all, he can then start to dig around, search
> >through kernel memory for patterns (e.g. module structure, modifications
> >in the network code, ...), insert his own modules, and basically
> >arbitrary things. So shouldn't it be easy to detect the presence of
> >Sebek by searching through the memory for the constant strings? Or
> >triggering a little fork bomb and see whether the system behaves unusual
> >compared to normal behavior?
>
> Heh, yeah that was the point I was leading up to, which is to say if
> you have root you can then do pattern matching on kernel memory
> to identify interesting things. This is true regardless of kernel patch
> or module.
>
> >>As for a patch, it does offer some advantages, however I am skeptical
> >> that it will be the magic fix. First most of the detection stuff we
> >>have seen is pattern match based. Going to kernel patch, just changes
> >>the patterns that one needs to looks for. Second, once you have
> >>patched the kernel, detection can happen on there kernel image in the
> >>fs itself.
> >
> >
> >I agree that it will not be the magic fix, but it can help the more
> >paranoid people. After all, Sebek is then part of the kernel and
> >removing it becomes much harder.
>
> Yes but you trade detectablity for a vague sense of security that you
> will be able to not disable a kernel patch. For example if I know where
> in memory the destination IP information or other parts of the config
> are stored, can't I manipulate them to send the data to the incorrect
> remote
> host making the collector blind?
>
In sebek environment, we better disable /dev/{kmem,mem}, together with
loading module capability. Then nobody can no longer access to kernel
memory, no?
> >
> >And if we observer the kind of detection techniques you mention, we can
> >start to add polymorphism ;-)
> >
> >>The one thing that is pretty sweet about a patch is that you dont
> >>need to worry about how to reinstall the kernel module after reboot.
> >
> >
> >Another option is detailed in "Infecting loadable kernel modules",
> >Phrack Volume 0x0b, Issue 0x3d, Phile #0x0a
> >(http://www.phrack.org/phrack/61/p61-0x0a_Infecting_Loadable_Kernel_Modules.txt)
> >
> >I hope that there will be soon a diploma thesis about improving the Data
> >Capture mechanism at my Lab. I keep you up-to-date on this topic.
> >
> It would be really sweet if someone could crank out a port of linux sebek
> which operated as a kernel patch and then did a comparision of the two
> regarding the situations to which each was best suited. There are a
> lot of assumptions about what a kernel patch can do for us, sounds
> like a perfect opportunity to test them ;-)
>
OK, I will work out a patch and let you know then.
Thanks.
Hieu
Received on Oct 05 2005
Intro
