Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

github.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#11

Post by saagarjha »

geofft wrote: post #8
saagarjha wrote: post #5

Earlier quoted context omitted.

> It seems like it's mostly useful for cases where people are blocking the ptrace syscall (like Docker's default syscall filter, maybe?) and not loading an LSM. It’s a shot in the dark, but I’d guess this is designed to work with programs that neuter themselves or commit suicide if you ptrace them, as is common for mildly sophisticated malware or (less often) CTF challenges.

How do you detect that you're being ptraced? I see the link to https://www.aldeid.com/wiki/Ptrace-anti-debugging in the README, but a) the program has to actively run its check while being ptraced to notice. If you attach to the program (which pauses it), inject your code, run your code, and then detach, the program's own code will not notice it's being ptraced, no? b) if you want to run the program's own code while…

Some of the detection methods methods were mentioned in a comment (here’s one more: timers), but I should also mention that some binaries try to resist ptrace attempts with ptrace(PTRACE_TRACEME, …) as well if you’re too slow to get in before that.

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#12

Post by geofft »

therein wrote: post #10
geofft wrote: post #8

Earlier quoted context omitted.

How do you detect that you're being ptraced? I see the link to https://www.aldeid.com/wiki/Ptrace-anti-debugging in the README, but a) the program has to actively run its check while being ptraced to notice. If you attach to the program (which pauses it), inject your code, run your code, and then detach, the program's own code will not notice it's being ptraced, no? b) if you want to run the program's own code while…

> a) the program has to actively run its check while being ptraced to notice. If you attach to the program (which pauses it), inject your code, run your code, and then detach, the program's own code will not notice it's being ptraced, no? Depends on if all threads were put into a paused state. Also, the program that's being debugged might have spawned some additional processes that will be checking if the parent is b…

Ahhh, yes, it's probably hard to track down a random subprocess somewhere that's checking and then passing that info back to the original process. (I think the subprocess could even just try to PTRACE_ATTACH the original process and see if it works.)

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#14

Post by DavidBuchanan »

quotemstr wrote: post #13

If you want to avoid the side effects of SIGSTOP, you can put the target process in a freezer cgroup instead.

This was recently suggested to me on Twitter, I'll have a look at implementing it tomorrow.

https://twitter.com/arnaud_lb/status/1212512382859251712

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#15

Post by kccqzy »

saagarjha wrote: post #11
geofft wrote: post #8

Earlier quoted context omitted.

How do you detect that you're being ptraced? I see the link to https://www.aldeid.com/wiki/Ptrace-anti-debugging in the README, but a) the program has to actively run its check while being ptraced to notice. If you attach to the program (which pauses it), inject your code, run your code, and then detach, the program's own code will not notice it's being ptraced, no? b) if you want to run the program's own code while…

Some of the detection methods methods were mentioned in a comment (here’s one more: timers), but I should also mention that some binaries try to resist ptrace attempts with ptrace(PTRACE_TRACEME, …) as well if you’re too slow to get in before that.

This might be off topic but I never really understood the utility of PTRACE_TRACEME. The documentation suggests that the parent must be a cooperating process (the wording "probably shouldn't" in the documentation is very suspicious). But if the parent knows it will ptrace the child, it could very well set up a pipe and have the child be blocked on it, then PTRACE_ATTACH, then unblock the child with the pipe.

As such, I never truly understood the semantics behind PTRACE_TRACEME, and I'm not sure what bad things will happen if you use that when the parent isn't expecting to ptrace the child.

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#16

Post by saagarjha »

kccqzy wrote: post #15
saagarjha wrote: post #11

Earlier quoted context omitted.

Some of the detection methods methods were mentioned in a comment (here’s one more: timers), but I should also mention that some binaries try to resist ptrace attempts with ptrace(PTRACE_TRACEME, …) as well if you’re too slow to get in before that.

This might be off topic but I never really understood the utility of PTRACE_TRACEME. The documentation suggests that the parent must be a cooperating process (the wording "probably shouldn't" in the documentation is very suspicious). But if the parent knows it will ptrace the child, it could very well set up a pipe and have the child be blocked on it, then PTRACE_ATTACH, then unblock the child with the pipe. As such,…

As I understand it, PTRACE_TRACEME causes the process to be put into "traced" mode, where signals (and exec* calls, which will cause a SIGTRAP to be sent) cause the process to stop. This is useful in the context of a debugger because the debugger process will fork, the child will call ptrace(PTRACE_TRACEME, …) to put itself into "traced" mode, then exec the process you want to debug and be conveniently placed into ptrace stop at the first instruction to be executed in the new binary.

The problem with PTRACE_TRACEME is that if you do it to yourself and recieve a signal, you're put into ptrace stop there's and there's no way out of it unless the parent knows how to get you out of it (using ptrace, of course). Sending signals will not work, even SIGKILL; somewhat humorously, on iOS, if you attempt to do the equivalent (using the similar PT_TRACE_ME) and oops yourself, the entire system will slowly grind to a halt as it tries to (at least, I think…) SIGKILL your process for a variety of reasons and fails, at some point locking up waiting for process termination.

Re: Show HN: dlinject.py – Inject a .so into a running Linux process, without ptrace

#20

Post by antpls »

geofft wrote: post #2

The tl;dr of the technique is to use /proc/$pid/mem to overwrite the stack. (Since you don't have direct control of the instruction pointer this way, there's some complexity in loading shellcode somewhere and having the process return to it to get it to usefully execute your code, much like an actual stack-corruption exploit.) On a normal Linux system, /proc/$pid/mem is protected by the same kernel permission check a…

> If you really want to do syscall filtering to confine an untrusted process (as opposed to reducing attack surface from potential bugs in otherwise-permissible syscalls, which is I think Docker's goal), you need to start from empty and allow syscalls instead of starting from full and blocking them. Alternatively, maybe just run the untrusted code as another user account or something.

It looks like the gVisor approach for containers (reimplementing parts of the kernel syscalls in userspace and disallowing the rest)

Post reply on HN