Linux: add member presence checks to linux.checks_afinfo

[eve-mem]

Hello!

Issue #832 is tracking the fact that newer kernels (from around 2018) won't have the required members for the hooking checks to be performed in this way.

This PR adds some checks around the members of the objects in the _check_afinfo function so that a more informative warning is displayed rather than simply crashing. Does this seem like a good idea?

[Abyss-W4tcher]

Hello, do you think redirecting users to https://github.com/AsafEitani/rootkit_plugins/blob/main/plugins/check_seqops.py, or directly merging both plugins would be a solution ?

They work toward the same goal in the end :)

Regards

[eve-mem]

@Abyss-W4tcher - I'd imagine that's certainly a possibility if @AsafEitani wanted to make a PR. My understanding is that @atcuno is looking into the way that this issue should be fixed fundamentally, and it might well be by updating it to do similar things to that seqops plugin.

I'm not sure that a framework plugin would every redirect users to a community plugin, but I'd let the core devs make that call. Maybe you and I could help more on the community support side of things and point people to these other resources when it pops up (exactly like you did in the issue comments for #832)

🦊 just a random internet vol user

[ikelos]

Looks pretty good to me, just wondering how useful the debugging message is, given it traverse the loop twice every single item its called on, seemingly with not a great value?

[ikelos]

Hmmm, I know it's not a big deal, but this is traversing all the elements do output the debug information, and then does it again (effectively) as part of the any operator. The debug information will probably only be checked if they're all false, so it might not be useful at all?

[eve-mem]

Yes, I agree with you. Not the best.

I wanted to have some difference between "The plugin run and there was no output, because there was nothing hooked" and "The plugin run and there was no output, because the kernel version isn't supported".

The later might lead to a false sense of security. I'll work up a better way to show that difference.

[eve-mem]

I've tweaked this now, but might be abusing the PluginRequirementException - let me know what you think.

[eve-mem]

Hello @ikelos

I've tweaked the logic for debug and warning messages. This removes the loops through the same parts twice, and also means that if every check with _check_afinfo fails you'll get a single warning message. Previously this change would have some a warning for every single symbol without the right members - which is quite spamy. It would be 6 warnings with the current plugin.

I may be abusing the PluginRequirementException to do it however... what do you think? I originally used an attribute error, but thought catching those might hide other problems in the future somehow. Maybe there is a better way to do this?

I'm just keen to show the difference between "no results, all is fine" and "no results, because the plugin couldn't check".

[ikelos]

Yep, looks good, thanks! Much happier about the logging and checks.. 5:)

[ikelos]

As to the PluginRequirementException, I think it's the right one to use, even if there isn't an explicit requirement exception. Kinda makes me wonder how we'd make an exception like that? I guess we'd need to check that a kernel symbol containing the kernel version was within certain bounds, but that might not be accurate. Defining a requirement on each of the required members would be cumbersome too. I think this works best, I didn't even know we had that exception, but I think it's the right one. If it causes any problems we can swap it out... 5:)