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?
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.
> 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."
/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.