3 ms·
> Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? Unless I'm mistaken, this should restrict what you can do with ROP gadgets that contain syscal
by gary_0 3y ago
> Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right?
Unless I'm mistaken, this should restrict what you can do with ROP gadgets that contain syscalls. You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed.
> I would also think this would cause problems for JITed code
They can probably just jump into precompiled code that performs the needed syscall. Also, making syscalls directly from something like JITed JavaScript is generally avoided anyways. AFAIK browsers don't even let the processes that run JavaScript touch much of the system at all, instead they have to use an IPC mechanism to ask a slightly more privileged process to perform specific tasks.
- woodruffw 3y ago> You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed. That makes sense, although "intended" arguments here means still being able to invoke `execve(2)`, etc., right? The gadget will still be able to mangle whatever it likes into the arguments for that syscall; it just won't be able to mangle a `wait(2)` into an `execve(2)`, I think. Your points about JITs make sense, thanks.
- gary_0 3y agoYes, that's how I understand it; you can't mangle one syscall into another, but you can still mangle the syscall's other argument values.