logoalt Hacker News

snarfy11/08/20243 repliesview on HN

One of the solutions listed to discovering this is to investigate /proc/mounts and look for these type of mounts. Couldn't you use the same trick on /proc/mounts itself?


Replies

theamk11/09/2024

/proc/mounts is a symlink to /proc/self/mounts. And /proc/self is a symlink to /proc/$PID. Those symlinks could be trivially bind-mounted, but you don't have to use them.

Instead, you can do something like "cat /proc/$$/mounts" - that will check the mounts file directly, from location like /proc/14102/mounts. That location is much harder to bind-mount over, as there are many processes and process IDs are hard to predict.

That said, to bind-mount, malware must have a root; and if malware has a root, it can do much better than playing silly tricks with bind-mounting over /proc - it can load a kernel rootkit to hide itself very effectively. That's why all investigation of potentially compromised machines must be done from known-clean OS.

chatmasta11/08/2024

I had the same thought, but I suspect that would break the mount. It might make the entire /proc/mounts directory appear empty but none of the mounts would work.

akira250111/08/2024

> Couldn't you use the same trick on /proc/mounts itself?

Unfortunately, yes. 'bind' allows mount to bind over individual files and not just directories. Which is a little bit insane.

In any case, if you are suspicious, 'umount /proc/mounts'. It either returns ok or it returns "umount: /proc/mounts: not mounted."