11

A popular way of hiding the processes from the user is to hijack the iterate function for the /proc directory. This can be done as follows:

struct file *filep = filp_open("/proc", O_RDONLY, 0));
filep->f_op->iterate = p // We swap the pointer with our hacked iterate

I am working on a detection method, where I would like to restore the original iterate function (assuming it has already been hijacked). Is there some way to find the original iterate function which is used for the /proc directory?

AlexSee
  • 322
  • 3
  • 16
  • 1
    You can use [proc_map_files_readdir](http://lxr.free-electrons.com/source/fs/proc/base.c#L1841) directly. Of course, if the attacker has write access to kernel he can change that as well. – zch Jan 17 '15 at 14:36
  • @zch Could you tell me how I can access this function? It's not present in the sysmap. – AlexSee Jan 17 '15 at 15:06
  • Right, it's a static function, so I'm not sure if this symbol will even be present in resulting kernel. You can try to mount second `procfs` and perhaps there you can detect some simple attacks of this kind. – zch Jan 17 '15 at 16:11
  • I tried mounting a second `procfs`, also played around with unmounting the original one but unfortunately it doesn't work. All of them show the same information, even if iterate is hijacked only once for `/proc`. – AlexSee Jan 17 '15 at 17:16
  • 1
    If your code kicks in after the hijack, there is no telling which was the original iteration function unless you have the current running kernel code. If you can assume proc_map_files_readdir is the iteration function that was hijacked, you can implement it yourself and point the iteration function to it. This should give you the same effect as the original function without the need to access it separately – Ishay Peled Apr 29 '15 at 10:21

2 Answers2

1

You can try a heuristic approach. The address of the original function will be in the same general area as the other proc functions, while the address of the hijacker function will be noticeably different. Then you parse the machine code of the hijacker function. The hijacker function will have to branch to the original function before it returns, so you look at all the branch instructions and check which one would fit to the other original addresses.

John Hammond
  • 467
  • 1
  • 4
  • 14
0

I assume you know which version of the kernel you are using?

Just copy that version of the function into your module and override the iterate pointer with your copy's address.

This should be functionally equivalent, though there is no telling what other evils the rouge module might have unleashed.

wkz
  • 2,203
  • 1
  • 15
  • 21
  • I'm afraid it's not that easy, when you copy the function verbatim there's still a lot of other stuff this function needs and which it cannot find in the module's address space. Perhaps it is somehow possible but I didn't manage to compile it. – AlexSee Oct 29 '15 at 23:09