RE: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall
Hi, Jann, Andy, Alexei, Kees and Paul: thanks a lot for your comments on my RFC!!. There were a few important points that I didn't mention but are critical to understand what I was trying to do. The focus of the patch was on protecting "real-time embedded IoT devices" such as a PLC (programmable logic controller) inside a factory assembly line . They have a few important properties that I took into consideration: - They often rely on firewall technology, and are not updated for many years (~20 years). For that reason, I think that a white-list approach (define the correct behaviour) seems suitable. Note also that the typical problem of white list approaches, false-positives, is unlikely to occur because they are very deterministic systems. - No asynchronous signal handlers: real-time applications need deterministic response times. For that reason, signals are handled synchronously typically by using 'sigtimedwait' on a separate thread. - Initialization vs cycle: real-time applications usually have an initialization phase where memory and stack are locked into RAM and threads are created. After the initialization phase, threads typically loop through periodic cycles and perform their tasks. The important point here is that once the initialization is done we can ban any further calls to 'clone', 'execve', 'mprotect' and the like. This can be done already by installing an extra filter. For the cyclic phase, my patch would allow enforcing the order of the system calls inside the cycles. (e.g.: read sensor, send a message, and write to an actuator). Despite the fact that the attacker cannot call 'clone' anymore, he could try to alter the control of an external actuator (e.g. a motor) by using the 'ioctl' system call for example. - Mimicry: as I mentioned in the cover letter (and Jann showed with his ROP attack) if the attacker is able to emulate the system call's order (plus its arguments and the address from which the call was made) this patch can be bypassed. However, note that this is not easy for several reasons: + the attacker may need a long stack to mimic all the system calls and their arguments. + the stealthy attacker must make sure the real-time application does not crash, miss any of its deadlines or cause deadline misses in other apps [Note] Real-time application binaries are usually closed source so this might require quite a bit of effort. + randomized system calls: applications could randomly activate dummy system calls each time they are instantiated (and adjust their BPF filter, which should later be zeroed). In this case, the attacker (or virus) would need to figure out which dummy system calls have to be mimicked and prepare a stack accordingly. This seems challenging. [Note] under a brute force attack, the application may just raise an alarm, activate a redundant node (not connected to the network) and commit digital suicide :). About the ABI, by all means I don't want to break it. If putting the field at the end does not break it, as Alexei mentioned, I can change it. Also I would be glad to review the SECCOMP_FILTER_FLAG_TSYNC flag mentioned by Jann in case there is any interest. However, I'll understand the NACK if you think that the maintenance is not worth it as Andy mentioned; that it can be bypassed under certain conditions; or the fact that it focuses on a particular type of systems. I will keep reading the messages in the kernel-hardening list and see if I find another topic to contribute :). Thanks a lot for your consideration and comments, Daniel
Re: [kernel-hardening] Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall
On Fri, Jan 22, 2016 at 4:23 PM, Kees Cook wrote: > Yeah, and if we break abi, we need to add further sanity checking to > the parser to determine which "version" of seccomp_data we need. I'm > not convinced that there is enough utility here to break ABI. PLEASE do not break the seccomp ABI for this alone ... I'm still trying to sort out the well intentioned, but extremely annoying direct-wired x86 socket syscalls in 4.4 for libseccomp, I don't want to have to deal with another big change for at least a month or two ;) > (Though if we do, I'd like to add tid to the seccomp_data, which has > been requested in the past to make some pid-based arg checks easier to > do.) Agreed, if we break anything, please add this. -- paul moore www.paul-moore.com
Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall
On Fri, Jan 22, 2016 at 9:30 AM, Alexei Starovoitov 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. >> >> Signed-off-by: Daniel Sangorrin > ... >> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h > ... >> struct seccomp_data { >> int nr; >> + int prev_nr; >> __u32 arch; >> __u64 instruction_pointer; >> __u64 args[6]; > > this will break abi for existing seccomp programs. > New field has to be at the end. Yeah, and if we break abi, we need to add further sanity checking to the parser to determine which "version" of seccomp_data we need. I'm not convinced that there is enough utility here to break ABI. (Though if we do, I'd like to add tid to the seccomp_data, which has been requested in the past to make some pid-based arg checks easier to do.) -Kees -- Kees Cook Chrome OS & Brillo Security
Re: [RFC PATCH 1/1] seccomp: provide information about the previous syscall
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. > > Signed-off-by: Daniel Sangorrin ... > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h ... > struct seccomp_data { > int nr; > + int prev_nr; > __u32 arch; > __u64 instruction_pointer; > __u64 args[6]; this will break abi for existing seccomp programs. New field has to be at the end.
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 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
Re: [kernel-hardening] [RFC PATCH 1/1] seccomp: provide information about the previous syscall
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? However, when exploiting network servers, this magic gadget won't help much - an attacker would probably have to either call into an interesting function in the application or use ROP. In the latter case, this protection won't help much - especially considering that most syscalls just return -EFAULT / -EINVAL when you supply nonsense arguments, ROPping through a "pop rax;ret" gadget and a "syscall;ret" gadget should make it fairly easy to bypass the protection. There are a bunch of occurences of both gadgets in Debian's libc (and these are just the trivial ones): $ hexdump -C /lib/x86_64-linux-gnu/libc-2.19.so | grep '58 c3' 000382e0 00 00 48 8b 00 5b 8b 40 58 c3 48 8d 05 4f 8a 36 |..H..[.@X.H..O.6| 000383b0 58 c3 48 8d 05 87 89 36 00 48 39 c3 74 0e 48 89 |X.H6.H9.t.H.| 00038450 40 58 c3 48 8d 05 e6 88 36 00 48 39 c3 74 0e 48 |@X.H6.H9.t.H| 000d9a00 48 89 44 24 18 e8 56 ff ff ff 48 83 c4 58 c3 90 |H.D$..V...H..X..| 000e51d0 c3 0f 1f 80 00 00 00 00 48 8b 40 58 c3 0f 1f 00 |H.@X| 000ea2f0 48 83 3d 58 c3 2b 00 00 48 8b 1d 69 8b 2b 00 64 |H.=X.+..H..i.+.d| 00160520 48 c3 fa ff 58 c3 fa ff 68 c3 fa ff 80 c3 fa ff |H...X...h...| 00171470 58 c3 f8 ff 84 60 02 00 74 c3 f8 ff 94 62 02 00 |X`..tb..| $ hexdump -C /lib/x86_64-linux-gnu/libc-2.19.so | grep '0f 05 c3' 000b85b0 b8 6e 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.n..| 000b85c0 b8 66 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.f..| 000b85d0 b8 6b 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.k..| 000b85e0 b8 68 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.h..| 000b85f0 b8 6c 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.l..| 000b87f0 b8 6f 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |.o..| 000d9260 b8 5f 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 |._..| 000e6400 b8 e4 00 00 00 0f 05 c3 0f 1f 84 00 00 00 00 00 || 000fff60 48 63 3f b8 03 00 00 00 0f 05 c3 0f 1f 44 00 00 |Hc?..D..| So an attacker would craft the stack like this: [pop rax;ret address] [first syscall for transition] [syscall;ret address] [pop rax;ret address] [second syscall for transition] [syscall;ret address] [...] [normal ROP for whatever the attacker wants to do] Maybe someone who knows a bit more about binary exploiting can comment on this, especially how likely it is that a manipulation of a network service's program flow is successful in the presence of full ASLR and so on without ROP. Also, there is a potential functional issue: What about signal handlers? Signal handlers will require transitions from all syscalls to any syscall that occurs at the start of a signal handler to be allowed as far as I can tell. > @@ -443,6 +448,11 @@ static long seccomp_attach_filter(unsigned int flags, > return ret; > } > > + /* Initialize the prev_nr field only once */ > + if (current->seccomp.filter == NULL) > + current->seccomp.prev_nr = > + syscall_get_nr(current, task_pt_regs(current)); > + > /* >* If there is an existing filter, make it the prev and don't drop its >* task reference. What about SECCOMP_FILTER_FLAG_TSYNC? When a thread is transitioned from SECCOMP_MODE_DISABLED to SECCOMP_MODE_FILTER by another thread, its initial prev_nr will be 0, which would e.g. appear to be the read() syscall on x86_64, right? signature.asc Description: Digital signature
[RFC PATCH 1/1] seccomp: provide information about the previous syscall
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. Signed-off-by: Daniel Sangorrin --- include/linux/seccomp.h | 2 + include/uapi/linux/seccomp.h | 2 + kernel/seccomp.c | 10 +++ samples/seccomp/.gitignore | 1 + samples/seccomp/Makefile | 9 ++- samples/seccomp/bpf-prev.c | 160 +++ 6 files changed, 183 insertions(+), 1 deletion(-) create mode 100644 samples/seccomp/bpf-prev.c diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h index 2296e6b..8c6de6d 100644 --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -16,6 +16,7 @@ struct seccomp_filter; * * @mode: indicates one of the valid values above for controlled * system calls available to a process. + * @prev_nr: stores the previous system call number. * @filter: must always point to a valid seccomp-filter or NULL as it is * accessed without locking during system call entry. * @@ -24,6 +25,7 @@ struct seccomp_filter; */ struct seccomp { int mode; + int prev_nr; struct seccomp_filter *filter; }; diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h index 0f238a4..42775dc 100644 --- a/include/uapi/linux/seccomp.h +++ b/include/uapi/linux/seccomp.h @@ -38,6 +38,7 @@ /** * struct seccomp_data - the format the BPF program executes over. * @nr: the system call number + * @prev_nr: the previous system call number * @arch: indicates system call convention as an AUDIT_ARCH_* value *as defined in . * @instruction_pointer: at the time of the system call. @@ -46,6 +47,7 @@ */ struct seccomp_data { int nr; + int prev_nr; __u32 arch; __u64 instruction_pointer; __u64 args[6]; diff --git a/kernel/seccomp.c b/kernel/seccomp.c index 580ac2d..98b2c9d3 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -190,6 +190,8 @@ static u32 seccomp_run_filters(struct seccomp_data *sd) sd = &sd_local; } + sd->prev_nr = current->seccomp.prev_nr; + /* * All filters in the list are evaluated and the lowest BPF return * value always takes priority (ignoring the DATA). @@ -200,6 +202,9 @@ static u32 seccomp_run_filters(struct seccomp_data *sd) if ((cur_ret & SECCOMP_RET_ACTION) < (ret & SECCOMP_RET_ACTION)) ret = cur_ret; } + + current->seccomp.prev_nr = sd->nr; + return ret; } #endif /* CONFIG_SECCOMP_FILTER */ @@ -443,6 +448,11 @@ static long seccomp_attach_filter(unsigned int flags, return ret; } + /* Initialize the prev_nr field only once */ + if (current->seccomp.filter == NULL) + current->seccomp.prev_nr = + syscall_get_nr(current, task_pt_regs(current)); + /* * If there is an existing filter, make it the prev and don't drop its * task reference. diff --git a/samples/seccomp/.gitignore b/samples/seccomp/.gitignore index 78fb781..11dda7a 100644 --- a/samples/seccomp/.gitignore +++ b/samples/seccomp/.gitignore @@ -1,3 +1,4 @@ bpf-direct bpf-fancy dropper +bpf-prev diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile index 1b4e4b8..b50821c 100644 --- a/samples/seccomp/Makefile +++ b/samples/seccomp/Makefile @@ -1,7 +1,7 @@ # kbuild trick to avoid linker error. Can be omitted if a module is built. obj- := dummy.o -hostprogs-$(CONFIG_SECCOMP_FILTER) := bpf-fancy dropper bpf-direct +hostprogs-$(CONFIG_SECCOMP_FILTER) := bpf-fancy dropper bpf-direct bpf-prev HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include HOSTCFLAGS_bpf-fancy.o += -idirafter $(objtree)/include @@ -17,6 +17,11 @@ HOSTCFLAGS_bpf-direct.o += -I$(objtree)/usr/include HOSTCFLAGS_bpf-direct.o += -idirafter $(objtree)/include bpf-direct-objs := bpf-direct.o +HOSTCFLAGS_bpf-prev.o += -I$(objtree)/usr/include +HOSTCFLAGS_bpf-prev.o += -idirafter $(objtree)/include +bpf-prev-objs := bpf-prev.o + + # Try to match the kernel target. ifndef CROSS_COMPILE ifndef CONFIG_64BIT @@ -29,10 +34,12 @@ MFLAG = -m31 endif HOSTCFLAGS_bpf-direct.o += $(MFLAG) +HOSTCFLAGS_bpf-prev.o += $(MFLAG) HOSTCFLAGS_dropper.o += $(MFLAG) HOSTCFLAGS_bpf-helper.o += $(MFLAG) HOSTCFLAGS_bpf-fancy.o += $(MFLAG) HOSTLOADLIBES_bpf-direct += $(MFLAG) +HOSTLOADLIBES_bpf-prev += $(MFLAG) HOSTLOADLIBES_bpf-fancy += $(MFLAG) HOSTLOADLIBES_dropper += $(MFLAG) endif diff --git a/samples/seccomp/bpf-prev.c b/samples/seccomp/bpf-prev.c new file mode 100644 index 000..138c584 --- /dev/null +++ b/samples/seccomp/bpf-prev.c @@ -0,0 +1,160 @@ +/* + * Seccomp BPF example that us