3 ms·
Syscall proxying was very old even when I wrote that article. The problem with syscall proxying is that it is slow. Take any process and imagine adding network
by grugq 3y ago
Syscall proxying was very old even when I wrote that article. The problem with syscall proxying is that it is slow. Take any process and imagine adding network latency to every single syscall. On a local network is incredibly slow, but over any sort of real distance it is just impossible.
That’s why I pushed everything to the target system. Run it local as much as possible.
Back then there were no containers or VMs to use. These days I think you should be bringing your environment with you. Unless there are serious reasons not to.
- joe_v 3y agoThat makes sense, something like `grep $USER /etc/passwd` would shuffle the whole passwd file over the wire, etc; for a lot of post-exploitation stuff I could see it causing more trouble than it's worth.
- grugq 3y agoOh, it’s far far worse than that. Just the core operation would be: open() — network round trip fstat() — network round trip brk() — network round trip read() — network round trip Shuffle data over network read() — network round trip Shuffle data over network Etc etc For a “grep root /etc/passwd” there are 88 syscalls on a Debian 11. If we assume a very generous 50ms latency for every syscall, that means we’re waiting 4.4s for the result. The use case for syscall proxying is limited to when you don’t want to upload an exploit onto a target machine, but you need to run the exploit on that machine. So it could be an LPE or something. It is way too slow for post exploitation work.