4 ms·
>> Process injection is the ability for one process to execute code in a different process This is the kind of absurd, foundation-shaking statement that, as so
by noduerme 4y ago
>> Process injection is the ability for one process to execute code in a different process
This is the kind of absurd, foundation-shaking statement that, as someone who's been coding since I was 7 (in 1987..) feels purely nauseating. Although I sort of know the answer, my first question is how did we reach the point where something so fundamental could be so insecure and distributed to so many people?
- 28194608 4y ago
- noduerme 4y agoThat's impressive. still not process injection unless it's still repeating itself every time I reload ;) [edit] oops. I reloaded. What was that script kiddy running against the server that generated all that text? Couldn't have been rendered on the client
- antientropic 4y agoThis is what happens when a new security model is retrofitted onto an existing one. In the original Unix security model, there was no security concern with this (except maybe for chroot environments): it didn't allow a process to do something it couldn't otherwise do, since all processes owned by a uid had exactly the same rights. Now that we've started sandboxing user processes in various ways on macOS and Linux, that's no longer the case, and we suddenly need to crack down on useful tools like strace and gdb.
- noduerme 4y agoSorry... this is above my pay grade, but I still think of processes as running on a single thread, reserving memory and being mostly inviolable other than maybe sampling what they're holding at the moment. How does giving a tool the ability to analyze a thread allow it to inject code into the process as it's running? Forgive me if I'm just way behind but isn't the kernel of any modern OS supposed to prevent exactly that thing from happening?
- korfuri 4y agoA lot of legitimate debugging features involve actually modifying the code of the target. This is a common way of setting breakpoints: you replace the instruction at the given address with a trap instruction that will hand control back to the debugger. Then the debugger puts the original instruction back and resumes the target's execution. And since the two processes already run as the same user, in the original model there's nothing the target can do that the debugger cannot also do, so this was not a privilege escalation path.
- noduerme 4y agoIf you're debugging as the same user that makes sense because the debugger is supervising the code. (the debugger can't for example halt other processes besides the code it's supervising). But how can some other random process even with the same user just inject itself into running compiled code without somehow having the ability to rewrite memory? [edit: memory that has already been allocated by the kernel for the thread it's trying to interfere with]
- hmage 4y agoThe difference between debugger and non-debugger in 80's unix is... none, besides calling ptrace(). I called ptrace() on your pid, therefore I am your debugger now.
- deleted 4y ago[deleted]
- 323 4y agoLD_PRELOAD, which is basically the same thing, has been with us since forever. Unix security model was never meant to protect user processes between themselves, it only meant to protect system from user apps, which is a bad model these days, where basically every device has a single user, and the real threat is user apps hacking and stealing each others data.
- anthk 4y agoOpenBSD has pledge(4) and unveil(4) today.