This happens on the latest ISO nixos-graphical-25.05.809619.d179d77c139e-x86_64-linux.iso and the checksum checked out, so seems like a false positive, but still felt the need to investigate. Should this be noted somewhere?
This seems like a tool that is designed for a standard Linux distribution that follows the FHS hierarchy. I have my doubts that it works even remotely well today, especially considering how many distributions out there may do similar things to NixOS and thus trigger false positives. I wouldn’t worry about this, imo.
Yeah, figured something along those lines. Unfortunately I recently received a laptop in the mail with a broken seal and had to at least try to make sure it hadn’t been tampered with. At a cursory glance chkrootkit and rkhunter seem to be the standard tools for doing that; rkhunter doesn’t seem to be available on nixpkgs so I ended up going with what was available.
Maybe a guide to verifying system integrity would be useful? Unfortunately I don’t have anywhere near the expertise to consider writing something like that.
You could try to mount the fs on a known clean device and run a nix store verify on the store. That’ll tell you if any of the files were altered by being on that system.
To verify if the upstream builders are infected you can build the derivations downstream explicitly with --offline and then compare checksums of the resulting files. The builds for these low-level components are pretty reliably reproducible so they should be identical (though tbf, if they aren’t, there’s a differential diagnosis here).
Benefits of reproducible builds right there
To assert there isn’t some kind of supply chain attack is harder. I doubt that an exploit disseminated through such an attack would be detected by your tool, since it relies on known signatures, but if you want to assert that isn’t the case, figure out what chrootkitthinks is embedded in there and disassemble the binaries yourself to check.
I mean I think the most useful thing to do would be to figure out whychkrootkit thinks those files are infected. Like try and get it to spit out a reason, or figure out what analysis it’s done.
(I realize this is all gradients and maybe this sounds contrived or silly, but depending on your threat model you really can’t do booted-system level checks to ensure you’re free of threat. Especially with UEFI, and the state of OEM security these days.
I doubt I’m the target of any state actors but I would be extremely paranoid/frustrated if I ordered a laptop and received it unsealed, for any reason.)
That’s fair. At least the laptop was still sealed in plastic; hardly perfect but better than nothing. I would’ve rejected it if it was new, but I bought it second-hand from a reseller so there was never any chance of receiving a risk-free device. Not that one exists anyway.
Before purchase I tried to find a guide for verifying Linux hardware second-hand, but found nothing. Ended up cobbling together a bunch of tools get a rough idea that the hardware is what the seller claims it is. Secure boot was turned on and everything working as far as I could tell, so I was never that concerned (especially with a clean install of NixOS). chkrootkit is obviously not the right tool for the job, but would be great to have some way of checking for possible threats that I’m not smart enough to consider.
Unfortunately what @colemickens means is that such a tool is effectively impossible to create. If the firmware of the device is compromised, no amount of scanning will help; it would always be capable of changing the result on-the-fly with you none the wiser. To a certain degree you simply have to trust that people aren’t out to get you specifically.
An OS wipe, perhaps a BIOS update just in case (not that it’d help if “they” were out to get you, realistically), and running fwupdmgr is the best you can do.
You can try scanning everything after a fresh install with clamav as a sort-of low-pass filter for really uncreative attempts to use a rootkit to install keyloggers into binaries that you install later, but such an exploit would be quite silly given the amount of power a rootkit has.
Nowadays, with eBPF, I’d say it’s essentially impossible to detect a well-designed rootkit running in kernel space. A userspace tool is so powerless.
I think you’re vastly overestimating how smart I am!
But I get the gist of it, it’s impossible to build a tool to automatically scan for threats specifically installed into your system. clamscan did come out as clean and BIOS has been updated relatively recently. Still need to check out fwupdmgr just to make sure.
Not that I disagree with the conclusion that chkrootkit is essentially useless, but I think there’s a “raising a bar” argument to be made here; in the real world, security is never a binary possible/impossible, but “how costly”.
Consider this: It’s theoretically entirely possible that my NixOS workstation has been infected and is, in fact, running Windows that has just been modified by an attacker to look like NixOS. If that is the case, I’d actually want to learn from that hacker.
Firmware rootkits and such are still more of a domain of academics and nation states. Also, deploying them comes with a cost; if a state X has a cool rootkit, it’s still much more valuable to them if there’s no awareness and good mitigations. In other words, the more costly the attack, the more valuable the target needs to be.
One could reasonably use the fTPM2 in the machine to regain some trust in it. The super early firmware secure boot chain on AMD and Intel machines these days is nothing to sneeze at, applies even when the UEFI “Secure Boot” feature is off, and also covers the fTPM2. You can check the fTPM2’s “endorsement key”, check that its certificate is signed by the vendor, and then use the TPM2 event log to audit the boot chain. As long as that firmware secure boot chain was secure, this is trustworthy. It is possible to break that, but it’s a much higher skill attack than just plopping a boot kit in NVRAM.
