Re: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall

On Fri, Jan 22, 2016 at 2:48 AM, Jann Horn [off-list ref] wrote:

On Fri, Jan 22, 2016 at 03:30:00PM +0900, Daniel Sangorrin wrote:

quoted

This patch allows applications to restrict the order in which
its system calls may be requested. In order to do that, we
provide seccomp-BPF scripts with information about the
previous system call requested.

An example use case consists of detecting (and stopping) return
oriented attacks that disturb the normal execution flow of
a user program.

The intent here is to mitigate attacks in which an attacker has
e.g. a function pointer overwrite without a high degree of stack
control or the ability to perform a stack pivot, correct? So that
e.g. a one-gadget system() call won't succeed?

Do you have data on how effective this protection is using just
the previous system call number?

I think that for example, the "magic ROP gadget" in glibc that
can be used given just a single pointer overwrite and stdin
control (https://gist.github.com/zachriggle/ca24daf4e8be953a3f96),
which (as far as I can tell) is in the middle of the system()
implementation, could be used as long as a transition to one of
the following syscalls is allowed:

 - rt_sigaction
 - rt_sigprocmask
 - clone
 - execve

I'm not sure how many interesting syscalls typically transition
to that, perhaps you can comment on that?

rt_sigaction is going to be a problem.  It can legitimately follow
*anything* because of async signals.

In general, I think I don't like this idea.  It seems like a hack that
we'll have to support forever that will allow semi-reliable IDS
signatures to break due to async signals and occasionally detect
intrusions that don't modify themselves slightly to evade detection.

--Andy