Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1315148
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall |
| Date | 2016-01-22 18:20 +0100 |
| Message-ID | <qTNxp-77w-11@gated-at.bofh.it> (permalink) |
| References | <qTDHH-e4-1@gated-at.bofh.it> <qTDHH-e4-15@gated-at.bofh.it> <qTHrY-2Ra-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jan 22, 2016 at 2:48 AM, Jann Horn <jann@thejh.net> wrote: > On Fri, Jan 22, 2016 at 03:30:00PM +0900, Daniel Sangorrin wrote: >> 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 0/1] Adding previous syscall context to seccomp Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> - 2016-01-22 07:50 +0100
[RFC PATCH 1/1] seccomp: provide information about the previous syscall Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> - 2016-01-22 07:50 +0100
Re: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall Jann Horn <jann@thejh.net> - 2016-01-22 11:50 +0100
Re: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall Andy Lutomirski <luto@amacapital.net> - 2016-01-22 18:20 +0100
RE: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall "Daniel Sangorrin" <daniel.sangorrin@toshiba.co.jp> - 2016-01-25 04:50 +0100
Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-01-22 18:40 +0100
Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall Kees Cook <keescook@chromium.org> - 2016-01-22 22:30 +0100
Re: [kernel-hardening] Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall Paul Moore <paul@paul-moore.com> - 2016-01-22 23:20 +0100
csiph-web