[HN Gopher] A free and open-source rootkit for Linux
___________________________________________________________________
A free and open-source rootkit for Linux
Author : jwilk
Score : 148 points
Date : 2026-01-18 09:36 UTC (13 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| jraph wrote:
| > 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.
| ilvez wrote:
| It's probably an old joke, but heard it here first. LOL
| jraph wrote:
| I don't know about you, but for ethical reasons, I only allow
| libre rootkits to run on my systems.
| sva_ wrote:
| Do you compile them yourself then? For possible arch
| specific optimizations
| da_chicken wrote:
| Are you even free if your rootkit isn't part of Gentoo
| Stage 0?
| fc417fc802 wrote:
| 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.
| throawayonthe wrote:
| 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
| fc417fc802 wrote:
| 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?
| reactordev wrote:
| They checked with their lawyers first... lol.
|
| Pretty sure all laws are null and void in their mind.
| jjmarr wrote:
| 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.
| written-beyond wrote:
| Thank you for the laugh!
| matheuzsec wrote:
| HAHAHAHAHAH I genuinely laughed a lot, thank you
| kazinator wrote:
| > _crime and an instance of copyright infringement._
|
| Well-made distinction; +1.
| Onavo wrote:
| 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
| XorNot wrote:
| 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)
| st_goliath wrote:
| > 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)
| fc417fc802 wrote:
| > 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.
| thwarted wrote:
| 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.
| fc417fc802 wrote:
| 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.
| XorNot wrote:
| 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.
| linuxftw wrote:
| > 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?
| fc417fc802 wrote:
| 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.
| bmitch3020 wrote:
| Previously discussed at
| https://news.ycombinator.com/item?id=46498658
| markus_zhang wrote:
| Ah this is so interesting. Rootkits are difficult to implement
| already, and RE them definitely is another level. Now we have a
| guidance.
| sabdarmdhn wrote:
| Since i dont know about Linux Rootkit, isnt this gonna raise the
| potential of Cyberattack?
| Retr0id wrote:
| No, plenty of open-source linux rootkits already exist
| (although this one does look more modern/maintained than most).
| TacticalCoder wrote:
| > 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.
| suprjami wrote:
| Looks like yes
|
| grep FTRACE /boot/config*
| siliconunit wrote:
| 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
| void-star wrote:
| 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.
| kazinator wrote:
| Sorry, I like my rootkits proprietary, closed-source, with a
| click-through/shrinkwrap EULA.
| exabrial wrote:
| > 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
___________________________________________________________________
(page generated 2026-01-18 23:00 UTC)