Thus spake Krzysztof Zaraska (kzaraskastudent.uci.agh.edu.pl):

> # kldload trojan.ko && rm /modules/trojan.ko

No need to rm it. You can manipulate the ufs vnode layer to hide
this file. See http://www.r4k.net/mod/

> So the only alert you may get from tripwire is that ctime of /modules is
> changed.

see above.

> I thing the original question was: how to find a trojaned module in
> memory if there's no relevant binary on disk?

Write a module that checksums the relevant parts of kernel, the
linker_file list and similar in-kernel stuff (e.g. accesses to
all functions that are needed to load the trojan module). Be sure
to hide this module as well. If an attacker isn't aware of such a
module, he won't try to circumvent it. If he's aware, it's still
hard to find and circumvent it, before his trojan module got loaded.
It's even harder if he doesn't know what internal functions and
data structures your module uses, so be sure to write your own :)

> We may also consider adding a feature to kldload to load only modules
> from under /modules but I'm afraid this may be circumvented by attacker
> fetching her own kldload.

You can still use /dev/mem.

Oh, and if you are able to load a module in securelevel >= 1 mode,
you are probably also able to tell kldload to load from other pathes :)

Alex

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]