5 ms·

If you have the privilege to pull off bind-mounting on top of a particular process directory in /proc you should also be able to mount something on top of /proc

If you have the privilege to pull off bind-mounting on top of a particular process directory in /proc you should also be able to mount something on top of /proc itself that will present a false /proc/mounts and conceal your trickery. I experimented a bit and wasn't able to bind a single file on top of /proc/mounts and I seem to be having trouble getting procfs to participate in an overlayfs, but if you were really dedicated you could construct a whole fake /proc by hand, or create something using FUSE to create a /proc that redacts anything you want, including mountpoints.

indigodaddy 2y ago
Interesting. Could you not perhaps tank the system attempting something like that?
- yjftsjthsd-h 2y ago
  How? I don't think the kernel cares what the directory looks like - userspace will break in funny ways, but you can boot without procfs even mounted (well, I say boot, but more like "you can start a shell and some things will still work")
  - tetris11 2y ago
    TIL that the kernel presents /proc as a convenience to the user, and does not actively read from it
    - yjftsjthsd-h 2y ago
      It might help to think of how it's implemented: When your application calls open() or read() or stat() or whatever, it passes through libc and then makes a syscall to ask the kernel "hey, give me a file handle for /proc/foo", "hey, give me the first 500 bytes from this file handle", etc. Then in the kernel, that syscall triggers a function that figures out what filesystem you're talking to and passes the request to that filesystem driver. AFAIK, the procfs driver just reads (and writes) a bunch of data structures in kernel memory and passes the result through as a filesystem. So the actual underlying data structure does always exist and is a hard requirement for the system to work, but procfs is just a userspace view into that underlying data in the kernel. Incidentally sysfs would be the same - the stuff you see in /sys exists in the kernel regardless, but the kernel doesn't really care whether those data structures are exposed to userspace as a virtual filesystem.
      - tetris11 2y ago
        Thanks for this extra context! I wonder now how much latency the system experiences with the procfs driver loaded. I'm guessing virtually none, but still, for a driver that is essentially just decoration for userspace to look at, it seems like there would be some noticeable overhead in having the procfs driver loaded
        yjftsjthsd-h 2y ago
        I wouldn't think so, no. If userspace isn't using it, then there's no latency overhead; the kernel access its own internal data structures the same regardless. If userspace is using it, the kernel still uses its own data structures just the same, but now there's a way for programs to read those data structures. Using the procfs driver doesn't change anything inside the kernel (well, anything important; obviously it exercises the procfs driver code (which also will have its own variables) and there's some data structures that describe mounted filesystems), it just provides an interface to what's already there.
- jordemort 2y ago
  Oh yes, very easily, although you'd be surprised at how much works without a functional /proc.
eptcyka 2y ago
Can you do similar trickery to ensure `mount` doesn't list your bind mount?
- duskwuff 2y ago
  I don't see why not - that's just reading from /proc/mounts.
  - dredmorbius 2y ago
    Nitpicking: mount reads from /proc/self/mounts, that is, the mounts as seen from that process. This is how tricks such as chroot jails work, as they present a different mount set and filesystem tree from the base system.
    - duskwuff 2y ago
      Same thing, really - /proc/mounts is a symlink to /proc/self/mounts.
      - dredmorbius 2y ago
        Fair enough, though casual readers may not realise this.
    - caf 2y ago
      chroot is a different, older system that pre-dates different mount namespaces.
      - dredmorbius 2y ago
        My understanding is that chroot presently does make use of the different mount namespaces, though I could be wrong here. How did chroot used to work in this regard? Were mountpoints outside the chroot jail itself accessible? Because if so, that ... would violate some key points of using a chroot jail in the first place. Though if chroot applied strictly to the filesystem and not mount points that might still offer benefits, and I seem to recall running into ... unexpected behaviours ... using chroots in the past.
compsciphd 2y ago
creating a whole fake proc is simple. I mean the code is already in the kernel as a module. Just copy it, put a few if/else's in the code to control what its readdir ( this case just pid's there's proc_readdir() that calls proc_pid_readdir(), just modify that very simply). mount is a bit harder (as its calls into code that is more in the core kernel fs code, but one can just reimplement it oneself, to filter out the mounts you don't want to show.
jasonjayr 2y ago
If you have root of course, you can do anything, BUT -- could a eBPF module be loaded into the kernel to just filter the syscalls to hide some nefarious process? This simplifies the 'evil VM' attack. Does eBPF have anything that could plausably help with that?
- tatref 2y ago
  https://sysdig.com/blog/ebpf-offensive-capabilities/ https://sysdig.com/blog/ebpf-offensive-capabilities/
- chucky_z 2y ago
  Pretty sure you can do this with standard MAC ala SELinux/AppArmor.
cedws 2y ago
If you have root you can just reboot or kexec and embed yourself at kernel level. The trick is to hide in plain sight. Call your process “tracker-miner-fs” (common suspiciously named GNOME process”). When the system administrator sees your process eating up huge amount of CPU time and does a web search, they’ll come to the conclusion it’s just GNOME being GNOME.
- arminiusreturns 2y ago
  You... I don't know if I love you or hate you. Signed, greybeard gnu/linux admin who hates procs like that! edit: this is also why lsof, ss, strace, and bpftrace etc., are helpful
_nalply 2y ago
A variant of hiding in plain sight for a backdoor if you have a webserver: create a directory ". " (dot space) somewhere in the web-application and put your backdoor in that directory. A sysadmin just would see . . .. as directory entries.

indigodaddy 2y ago

Interesting. Could you not perhaps tank the system attempting something like that?

yjftsjthsd-h 2y ago
How? I don't think the kernel cares what the directory looks like - userspace will break in funny ways, but you can boot without procfs even mounted (well, I say boot, but more like "you can start a shell and some things will still work")
- tetris11 2y ago
  TIL that the kernel presents /proc as a convenience to the user, and does not actively read from it
  - yjftsjthsd-h 2y ago
    It might help to think of how it's implemented: When your application calls open() or read() or stat() or whatever, it passes through libc and then makes a syscall to ask the kernel "hey, give me a file handle for /proc/foo", "hey, give me the first 500 bytes from this file handle", etc. Then in the kernel, that syscall triggers a function that figures out what filesystem you're talking to and passes the request to that filesystem driver. AFAIK, the procfs driver just reads (and writes) a bunch of data structures in kernel memory and passes the result through as a filesystem. So the actual underlying data structure does always exist and is a hard requirement for the system to work, but procfs is just a userspace view into that underlying data in the kernel. Incidentally sysfs would be the same - the stuff you see in /sys exists in the kernel regardless, but the kernel doesn't really care whether those data structures are exposed to userspace as a virtual filesystem.
    - tetris11 2y ago
      Thanks for this extra context! I wonder now how much latency the system experiences with the procfs driver loaded. I'm guessing virtually none, but still, for a driver that is essentially just decoration for userspace to look at, it seems like there would be some noticeable overhead in having the procfs driver loaded
      - yjftsjthsd-h 2y ago
        I wouldn't think so, no. If userspace isn't using it, then there's no latency overhead; the kernel access its own internal data structures the same regardless. If userspace is using it, the kernel still uses its own data structures just the same, but now there's a way for programs to read those data structures. Using the procfs driver doesn't change anything inside the kernel (well, anything important; obviously it exercises the procfs driver code (which also will have its own variables) and there's some data structures that describe mounted filesystems), it just provides an interface to what's already there.
jordemort 2y ago
Oh yes, very easily, although you'd be surprised at how much works without a functional /proc.

eptcyka 2y ago

Can you do similar trickery to ensure `mount` doesn't list your bind mount?

duskwuff 2y ago
I don't see why not - that's just reading from /proc/mounts.
- dredmorbius 2y ago
  Nitpicking: mount reads from /proc/self/mounts, that is, the mounts as seen from that process. This is how tricks such as chroot jails work, as they present a different mount set and filesystem tree from the base system.
  - duskwuff 2y ago
    Same thing, really - /proc/mounts is a symlink to /proc/self/mounts.
    - dredmorbius 2y ago
      Fair enough, though casual readers may not realise this.
  - caf 2y ago
    chroot is a different, older system that pre-dates different mount namespaces.
    - dredmorbius 2y ago
      My understanding is that chroot presently does make use of the different mount namespaces, though I could be wrong here. How did chroot used to work in this regard? Were mountpoints outside the chroot jail itself accessible? Because if so, that ... would violate some key points of using a chroot jail in the first place. Though if chroot applied strictly to the filesystem and not mount points that might still offer benefits, and I seem to recall running into ... unexpected behaviours ... using chroots in the past.

compsciphd 2y ago

creating a whole fake proc is simple. I mean the code is already in the kernel as a module. Just copy it, put a few if/else's in the code to control what its readdir ( this case just pid's there's proc_readdir() that calls proc_pid_readdir(), just modify that very simply). mount is a bit harder (as its calls into code that is more in the core kernel fs code, but one can just reimplement it oneself, to filter out the mounts you don't want to show.

jasonjayr 2y ago

If you have root of course, you can do anything, BUT -- could a eBPF module be loaded into the kernel to just filter the syscalls to hide some nefarious process? This simplifies the 'evil VM' attack. Does eBPF have anything that could plausably help with that?

tatref 2y ago
https://sysdig.com/blog/ebpf-offensive-capabilities/ https://sysdig.com/blog/ebpf-offensive-capabilities/
chucky_z 2y ago
Pretty sure you can do this with standard MAC ala SELinux/AppArmor.

cedws 2y ago

If you have root you can just reboot or kexec and embed yourself at kernel level. The trick is to hide in plain sight. Call your process “tracker-miner-fs” (common suspiciously named GNOME process”). When the system administrator sees your process eating up huge amount of CPU time and does a web search, they’ll come to the conclusion it’s just GNOME being GNOME.

arminiusreturns 2y ago
You... I don't know if I love you or hate you. Signed, greybeard gnu/linux admin who hates procs like that! edit: this is also why lsof, ss, strace, and bpftrace etc., are helpful

_nalply 2y ago

A variant of hiding in plain sight for a backdoor if you have a webserver: create a directory ". " (dot space) somewhere in the web-application and put your backdoor in that directory. A sysadmin just would see . . .. as directory entries.