# Chkrootkit reports \`basename\`, \`date\`, \`dirname\`, \`echo\` and \`env\` as infected on 25.05 live USB
**URL:** https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245
**Category:** Security
**Created:** [September 11, 2025, 2:44pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245 "2025-09-11T14:44:26Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@ArseAssassin](https://discourse.nixos.org/u/ArseAssassin)
#### Post date: [September 11, 2025, 2:44pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/1 "2025-09-11T14:44:26Z")
Running `chkrootkit` on a NixOS 25.05 gives the following output:
```auto
nix-shell -p chkrootkit
[nix-shell:~]$ sudo chkrootkit -q
[sudo] password for ****** :
Checking `basename'... INFECTED
/bin/sh
Checking `date'... INFECTED
Checking `dirname'... INFECTED
Checking `echo'... INFECTED
Checking `env'... INFECTED
...
```
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?
---
### Author:  [@pyrox](https://discourse.nixos.org/u/pyrox)
#### Post date: [September 11, 2025, 2:56pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/2 "2025-09-11T14:56:54Z")
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.
---
### Author:  [@ArseAssassin](https://discourse.nixos.org/u/ArseAssassin)
#### Post date: [September 11, 2025, 3:15pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/3 "2025-09-11T15:15:29Z")
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.
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [September 11, 2025, 7:39pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/4 "2025-09-11T19:39:31Z")
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 `chrootkit` _thinks_ is embedded in there and disassemble the binaries yourself to check.
---
### Author:  [@ElvishJerricco](https://discourse.nixos.org/u/ElvishJerricco)
#### Post date: [September 11, 2025, 7:41pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/5 "2025-09-11T19:41:12Z")
I mean I think the most _useful_ thing to do would be to figure out _why_ `chkrootkit` thinks those files are infected. Like try and get it to spit out a reason, or figure out what analysis it’s done.
---
### Author:  [@rnhmjoj](https://discourse.nixos.org/u/rnhmjoj)
#### Post date: [September 11, 2025, 10:37pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/6 "2025-09-11T22:37:36Z")
This program is big shell script™, so it’s pretty easy to figure out what it does.
For example, to conclude that `basename` is infected it’s doing
```auto
strings -a /run/current-system/sw/bin/basename | grep -E '^/bin/.*sh$|bash|elite$|vejeta|\.ark|iroffer'
```
The binary apparently contains the string `/bin/sh`, so it flags it.
Same thing for `dirname`, `echo` and `env`.
---
### Author:  [@colemickens](https://discourse.nixos.org/u/colemickens)
#### Post date: [September 11, 2025, 10:45pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/7 "2025-09-11T22:45:35Z")
> [@ArseAssassin](#):
>
> 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.
(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.)
---
### Author:  [@Sandro](https://discourse.nixos.org/u/Sandro)
#### Post date: [September 11, 2025, 10:46pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/8 "2025-09-11T22:46:36Z")
Lets drop that package [chkrootkit: drop by SuperSandro2000 · Pull Request #442222 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/442222)
---
### Author:  [@ArseAssassin](https://discourse.nixos.org/u/ArseAssassin)
#### Post date: [September 12, 2025, 8:44am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/9 "2025-09-12T08:44:29Z")
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.
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [September 12, 2025, 8:54am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/10 "2025-09-12T08:54:58Z")
> [@ArseAssassin](#):
>
> 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.
---
### Author:  [@rnhmjoj](https://discourse.nixos.org/u/rnhmjoj)
#### Post date: [September 12, 2025, 9:02am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/11 "2025-09-12T09:02:50Z")
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.
---
### Author:  [@ArseAssassin](https://discourse.nixos.org/u/ArseAssassin)
#### Post date: [September 12, 2025, 9:38am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/12 "2025-09-12T09:38:43Z")
> [@TLATER](#):
>
> > [@ArseAssassin](#):
> >
> > 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.
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.
Thanks everyone!
---
### Author:  [@sliedes](https://discourse.nixos.org/u/sliedes)
#### Post date: [September 12, 2025, 10:31am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/13 "2025-09-12T10:31:37Z")
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.
---
### Author:  [@TLATER](https://discourse.nixos.org/u/TLATER)
#### Post date: [September 12, 2025, 10:40am UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/14 "2025-09-12T10:40:18Z")
Which is precisely why I give the suggestion to use `clamav` as a low-pass filter and wipe whatever existing software is on the machine beforehand 😉
For most people that’s the reasonable limit of what can be achieved.
---
### Author:  [@ElvishJerricco](https://discourse.nixos.org/u/ElvishJerricco)
#### Post date: [September 12, 2025, 1:44pm UTC](https://discourse.nixos.org/t/chkrootkit-reports-basename-date-dirname-echo-and-env-as-infected-on-25-05-live-usb/69245/15 "2025-09-12T13:44:20Z")
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.