1

I'm trying to implement CreateRemoteThread in linux using ptrace. The main problem is that the mmap and clone system call is not signal-safe, so it's dangerous to inject them directly.

But what if I can make sure there is not pending mmap and clone system calls of that process in kernel?

For example, first I attach all the threads of target process and check if the previous 2 bytes of the rip is 0x0f 0x05(syscall). If it is, then get the syscall number from orig_rax reg and check if it's 9(mmap) or 56(clone). If so, I set the address in rip to 0xcc(int3) and continue that thread. When I receive the SIGTRAP from those threads, those system calls should be finished and there should be no not pending mmap and clone system calls in that process.

Is it safe to use mmap and clone system call now?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
WednesdayDT
  • 11
  • 4
  • I'm sure that all actual system calls including `mmap` can be called from signal handlers. `mmap` is not on the POSIX list because it might possibly not be a system call on some systems. Checking for op codes is definitely a bad idea. It's very likely to blow up in your face. If you want to trace currently executing system calls, check out how `strace` does it and copy the approach. – fuz May 19 '20 at 14:45
  • @fuz, Do you mean all the system calls are reentrant? – WednesdayDT May 19 '20 at 15:15
  • All system calls are reentrant. For some of them, the kernel will abort the system and return `EAGAIN` when a signal is delivered while the system call is blocking the process. However, this should really matter for you since you are in full control of the process and a signal has already been delivered (thus interrupting any interruptible system calls). – fuz May 19 '20 at 15:19
  • 1
    In general, the whole “async-signal-safe” thing is more about libc functions and portability. Every system call that may potentially not be a system call on other systems and that might need access to shared state is not async-signal safe. (you can't exactly use locks there because the process is suspended while the signal handler runs) – fuz May 19 '20 at 15:21
  • @fuz Thanks! As far as I know, the kernel will decrease rip by 2 to redo the system call automatically when I continue the thread.Is that because the systemcall abort? So there's no pending system call in kernel since when the signal is caught all the systemcall is aborted? – WednesdayDT May 19 '20 at 15:32
  • I can't say for sure. I suppose that could be a reason. – fuz May 19 '20 at 15:34
  • @fuz BTW, do you have and document about this or I have to read the code? – WednesdayDT May 19 '20 at 15:36
  • 1
    It's probably documented somewhere, but this is basically how it always worked on all UNIX-like systems. You can't break the kernel by doing concurrent system calls. – fuz May 19 '20 at 15:39
  • @fuz All right, Thanks a lot – WednesdayDT May 19 '20 at 15:41
  • Tangentially related: once you think you have your "CreateRemoteThread in Linux" working, see if it works with [this particular C program](https://gist.github.com/josephcsible/c8ce72a6084634fe56928c4bd20e6d52) as the target. I suspect it will not. – Joseph Sible-Reinstate Monica May 19 '20 at 18:46

0 Answers0