Ah this is so interesting. Rootkits are difficult to implement already, and RE them definitely is another level. Now we have a guidance.
A free and open-source rootkit for Linux
11–20 of 44 posts
Re: A free and open-source rootkit for Linux
#12Earlier quoted context omitted.
It's probably an old joke, but heard it here first. LOL
I don't know about you, but for ethical reasons, I only allow libre rootkits to run on my systems.
It's just like a gun free zone. You glue a prominent sign to your laptop that uses bright colors and an imposing font. "No proprietary software permitted!" Problem solved.
Re: A free and open-source rootkit for Linux
#13Re: A free and open-source rootkit for Linux
#14Man I just discovered this as a good guide on how to exceed the normal limits on Linux kernel modules. Been working on a derviative which hooks the VFS to allow dynamically remapping file paths on a per process basis so I can force badly behaved apps to load custom TLS certificates (looking at you Bazil builds in nixpkgs). (If anyone knows something which already does this it would save me a lot of yak shaving)
> how to exceed the normal limits on Linux kernel modules. Uh, what limits? I'm not aware of anything that would stop your module, once probed, from reaching around the back of the kernel and futzing around in the internals of another driver/device in a completely unrelated subsystem, or subsystem internals. SoC/SoM vendors love to pull that kind of crap in their BSPs. > hooks the VFS to allow dynamically remapping f…
> use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)
I think I would literally recompile libc to patch fopen/open/openat long before I would even begin to consider writing a kernel module to mess with filesystem paths on a per-process basis.
I feel like if you find yourself seriously considering writing a kernel module then you are either contributing to kernel development, or have embarked on an adventure specifically to learn about kernel internals, or have take a very wrong turn.
Re: A free and open-source rootkit for Linux
#15Man I just discovered this as a good guide on how to exceed the normal limits on Linux kernel modules. Been working on a derviative which hooks the VFS to allow dynamically remapping file paths on a per process basis so I can force badly behaved apps to load custom TLS certificates (looking at you Bazil builds in nixpkgs). (If anyone knows something which already does this it would save me a lot of yak shaving)
> Been working on a derviative which hooks the VFS to allow dynamically remapping file paths on a per process basis so I can force badly behaved apps to load custom TLS certificates (looking at you Bazil builds in nixpkgs). chroot or namespaces/containers?
Well he said nix so it's probably hardcoded to load from the store. Tampering with the store itself might have unintended consequences if anything else references the same certificate package.
Re: A free and open-source rootkit for Linux
#16Since i dont know about Linux Rootkit, isnt this gonna raise the potential of Cyberattack?
Re: A free and open-source rootkit for Linux
#17> The Ftrace mechanism can be disabled at run time, of course — so Singularity helpfully enables it automatically and blocks any attempts to turn it off.
Can a kernel be compiled with Ftrace forced off? If it can be disabled at runtime, I take it it's not mandatory for the kernel to work. And I don't just mean off: I mean striping the Ftrace code path (dead code elimination or whatever).
I'm also interested in other measures, like a unified kernel moreover without the ability to load modules but this is not what my question is about. I'd like to know if Ftrace can just be turned off for good at kernel compile time.
Re: A free and open-source rootkit for Linux
#18Since i dont know about Linux Rootkit, isnt this gonna raise the potential of Cyberattack?
No, plenty of open-source linux rootkits already exist (although this one does look more modern/maintained than most).
Re: A free and open-source rootkit for Linux
#19> If one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement. Too bad the author picked the MIT license. Had they picked (A)GPL, it would have forced the criminals to distribute a copy of LICENSE.TXT alongside their improved copy of the source code on systems they compromise.…
If I might interject for a moment, you should've recommended the (A)GPLv3.
The anti-tivoization clause in Version 3 would allow users to modify and replace the rootkit with their own, more or less malicious version, even if it would otherwise violate copyright law.
Re: A free and open-source rootkit for Linux
#20> If one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement. Too bad the author picked the MIT license. Had they picked (A)GPL, it would have forced the criminals to distribute a copy of LICENSE.TXT alongside their improved copy of the source code on systems they compromise.…
Thank you for the laugh!