A free and open-source rootkit for Linux | Hacker News Reader

A free and open-source rootkit for Linux

lwn.net

218 pointsjwilk40 comments

> 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. Failing this, using it in that way would be both a crime and an instance of copyright infringement.

Although, it occurs to me that if they don't give credits to the original author, it's also already a copyright infringement under the MIT.

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.

Do you compile them yourself then? For possible arch specific optimizations

Are you even free if your rootkit isn't part of Gentoo Stage 0?

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.

i think this comment is referring to the uniquely american controversy over "gun free zones", ie zones where... you aren't allowed to carry firearms by law, often marked with a sign

which i find very entertaining, saying "a sign can't stop a criminal!" as if that's not the case with any law enforced via threat of criminal prosecution

I don't think I'd call it a controversy exactly. There are places where the signs make sense (ex court buildings) and then there are places where they are purely performative. When a school in the ghetto that suffers gang related violence prominently posts such signs they rightfully get made fun of. Meanwhile most schools (at least where I grew up) either don't bother to post such signs or only post a subdued "all weapons illegal" near the entrance (that includes even pocket knives BTW it's not just a gun thing).

Another great one is "drug free zone" seen plastered all over a seedy highschool. Drugs are blanket illegal everywhere here. The US has made an art form out of persecuting drug users. We've peddled our "war on drugs" globally. What could possibly be the point of posting such a sign?

> What could possibly be the point of posting such a sign?

If you want a real answer, its increased penalties / extra charges if caught in the "zone".

They checked with their lawyers first… lol.

Pretty sure all laws are null and void in their mind.

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.

Thank you for the laugh!

HAHAHAHAHAH I genuinely laughed a lot, thank you

> crime and an instance of copyright infringement.

Well-made distinction; +1.

It's nice until you get spammed with emails from angry users. I think it happened to the sqlite and other popular open source project authors. Non technical users think they are polluting their computer.

https://news.ycombinator.com/item?id=42358470

It happened to thttpd

https://www.acme.com/software/thttpd/repo.html

The person in that thread could explain the situation a lot more better to the non technical users. You could do this:

"I don't know what happened to your computer but you seem to be saying someone hacked your computer and installed some software and you found acme.com mentioned on it. This was not done by me. acme.com is open source software that is freely available to anyone. This is the same as if someone installed software on your computer that mentions the google chrome web browser - that would not indicate google had anything to do with that action, since google chrome is freely available too."

This is why our temp files have names like malware_dropper.exe and bitcoin_scam.xls. If anyone sees those they assume it's some virus and don't bother us with them.

> 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.

Looks like yes

grep FTRACE /boot/config*

Previously discussed at https://news.ycombinator.com/item?id=46498658

Man 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 file paths on a per process basis

Instead of messing with kernel VFS internals, you could try:

- patching the offending application or package (ideally make the path configurable and contribute that back upstream)

- running the application in a mount namespace and bind-mount something over the path

- use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)

> 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.

LD_PRELOAD has nothing to do with the kernel, it's entirely resolved in user space; in this context, it would be used to replace libc functions.

> I think I would literally recompile libc to patch fopen/open/openat

That's literally the functionality that LD_PRELOAD provides without having to recompile libc.

Yes, I am aware. I was suggesting that even going to the ridiculous length of patching and replacing libc system wide would likely make more sense than authoring a custom kernel module to accomplish most tasks for which such options are applicable.

Statically compiled binaries don't use libc. Golang is one, anything with Rust and MUSL is another, and reliably injecting an environment variables into Nix is well..not reliable. It also links its own hashed libc paths which you can't predict and which shouldn't be different to any process which isn't trying to establish TLS connections.

It's not like I didn't try this stuff.

You can hook the system call to open a file regardless of libc use. If for some strange reason you really wanted to patch libc and the program you're using statically links it (ex musl) that isn't an issue - just patch the relevant libc implementation and recompile. But more generally, if you have access to the source code then why would you not directly patch the program in question instead of resorting to these sorts of shenanigans?

Seriously, you're doing it wrong. Just hook the relevant system call and be done with it. Your usecase is literally one of the first eBPF tutorials that comes up when looking for information about modifying system call arguments. https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/m...

> 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.

+1 for userns, there's also proot (userspace chroot) and fakechroot (using LD_PRELOAD).

Ah this is so interesting. Rootkits are difficult to implement already, and RE them definitely is another level. Now we have a guidance.

Sorry, I like my rootkits proprietary, closed-source, with a click-through/shrinkwrap EULA.

And then having to accept a privacy policy after you buy/install the rootkit.

> Users who feel their computers are too secure can install the Singularity kernel module in order to allow remote code execution, disable security features, and hide files and processes from normal administrative tools.

Hah

Since 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).

as much as I'm all for the freedom of knownledge, given the sorry state of the world, releasing these tools to imbecils is not peak foresight.. mcafee for linux next ha../s

Public Linux rootkits have been around a very very long time. Nothing new here in that regard. Also Linux AV has been around almost as long…

This effort is more useful to up and coming defenders and security researchers than attackers by far.

Most such rootkits source code is online and easy to find. So that rootkit finders get better.

Reply on news.ycombinator.com