On 07/06/2017 12:28 AM, R0b0t1 wrote: > To be fair it is a bit more circuitous on Linux than it is on Windows. > Even if you use (or abuse?) /proc as I outlined in my blurb on > GRsecurity you can't directly cause another process to start executing > your code directly, but you can edit its memory, debug it, and mess > with it in almost every other imaginable way - or you can just find a > way to get the user to execute some other executable you created on > disk. > > On Windows there exists CreateRemoteThread.[1] You can force a > currently loaded process to run whatever code you want.
Not sure what CreateRemoteThread has to do with exploitation. You can't inject code in a process with higher privileges than the process you're running as. > You can solve both of these problems with Role Based Access Controls, > if you want to bother setting them up. Otherwise process sandboxing > only applies to resources, not security. Security is a problem that is never completely solved. Sandboxing and RBAC are good mitigations to have in place. If you were able to get code execution within a browser that was sandboxed, you could still interact with the kernel and attempt to exploit it. This is where the kernel patches that grsec provides really help you out. As they make successful exploitation of the kernel more difficult.
