On Fri, Sep 11, 2020 at 04:29:16PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 4:03 PM, Segher Boessenkool
> > <seg...@kernel.crashing.org> wrote:
> >> The parameters that are passed to sys call will be destroyed, therefore,
> >> the attack will likely failed.
> >
> > But you do not need more than one non-zero argument for execv*, and that
> > is usually the same register as the normal return value register; all
> > other registers *should* be zero for a simple execv*("/bin/sh", ...)!
> >
> > (There is also the system call number register, rax on x86-64, but if
> > overwriting that would be any effective, you could just do that one
> > always and everywhere. This is only an effective defence if there are
> > no gadgets that do the system call an attacker wants, and he has to
> > construct that sequence himself; but it very effective and cheap then).
>
> In the above, do you mean only clearing “rax” on x86-64 should be effective
> enough?
(rax=0 is "read", you might want to do another value, but that's just
details.)
"This is only an effective defence if there are
no gadgets that do the system call an attacker wants, and he has to
construct that sequence himself; but it very effective and cheap then)."
It is definitely *not* effective if there are gadgets that set rax to
a value the attacker wants and then do a syscall. It of course is quite
effective in breaking a ROP chain of (set rax) -> (syscall). How
effective it is in practice, I have no idea.
My point was that your proposed scheme does not protect the other
syscall parameters very much either.
And, hrm, rax is actually the first return value. On most ABIs the
same registers are used for arguments and for return values, I got
confused. Sorry. So this cannot be very effective for x86-64 no
matter what.
Segher
