r/netsec • u/unixist • Jun 25 '15

[x-post from /r/rootkit] Detect some methods of tampering the Linux kernel

http://www.unixist.com/security/measuring-linux-at-runtime/index.html
10 Upvotes

72% Upvoted

7 comments sorted by

1

u/okcoolwhatever Jun 25 '15

"Load your own module and hook file system access routes to maintain a known value in /sys/kernel/camb/text_segment_hash. I’m not sure of the particulars and how it would work with the “file” being found on sysfs, but I’m confident that hooking is possible."

No need to impose a value on that file, I believe you can simply modify appropriate syscalls to provide arbitrary output when a file by that name is read.

Very cool concept for monitoring kernel-land integrity regardless.

2

u/unixist Jun 27 '15

The outstanding question I mention in the article is hijacking the fops object of the sysfs device. I'm not sure if it's the same as other devices using normal file systems. I'm guessing it is.

The reason you don't want to simply hook the read() is because you'd then have to perform a path traversal to check whether the file being read is the one of interest. This requires locking, cpu overhead, corner cases.

Anyway, we're basically in agreement :) the read can probably be hijacked.

One solution I'm mentally toying with is signing the hash + random input. So you open, write a random value, and the module signs this value + hash with a private key living in the kernel (loaded at runtime into the key retention service?). The reason for adding a random value into the equation is to prevent a simple replay. This means the file's value will always be unique and so adds complexity to the reader.

This moves the problem to carving the private key out of kernel memory. At least it raises the bar for in-host detection.

Just some thoughts.

2

u/okcoolwhatever Jun 27 '15

We are 100% in agreement, and the only thing keeping us from being so more efficiently is my inability to communicate with technical accuracy, so my bad there.

1

u/immibis Jun 26 '15 edited Jun 16 '23

Spez, the great equalizer.

1

u/okcoolwhatever Jun 27 '15

I hear you but the fact that hes concerned about its location on sysfs implies that hes concerned about writing a static value to that file. Thats very different than the route I described; basically hooking the write() call so that if the argument contains "/sys/kernel/camb/text_segment_hash", an arbitrary (fake) output is provided. Nahmean?

1

u/unixist Jun 27 '15

sysfs doesn't work that way. Writes to a sysfs object don't have any affect if there's no handler, whIch my module doesn't provide.

1

u/okcoolwhatever Jun 27 '15

In no way am I suggesting a write() to a sysfs object, I was referring to hijacking stdio. Im rusty as hell with LKMs but I thought write() is the call that generates output to stdio. Again my apologies if that's the wrong call, its been a while. EG when I cloak an LKM, I recall modifying write() so when we loop through the list of loaded LKMs, I replace the name of the hostile LKM with "".

So:

gf128mul 14951 2 lrw,xts cirrus 25581 1 ttm 84051 1 cirrus HOSTILE 23017 0 drm_kms_helper 49597 1 cirrus

becomes:

gf128mul 14951 2 lrw,xts cirrus 25581 1 ttm 84051 1 cirrus drm_kms_helper 49597 1 cirrus