linux-kernel - Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fbc1f44dffce6079fa7ec827c1b1e40e.squirrel@webmail.greenhost.nl>
Date:	Wed, 18 Jan 2012 13:12:42 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Chris Evans" <scarybeasts@...il.com>
Cc:	"Andi Kleen" <andi@...stfloor.org>,
	"Jamie Lokier" <jamie@...reable.org>,
	"Andrew Lutomirski" <luto@....edu>,
	"Oleg Nesterov" <oleg@...hat.com>,
	"Will Drewry" <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	torvalds@...ux-foundation.org, segoon@...nwall.com,
	rostedt@...dmis.org, jmorris@...ei.org, avi@...hat.com,
	penberg@...helsinki.fi, viro@...iv.linux.org.uk, mingo@...e.hu,
	akpm@...ux-foundation.org, khilman@...com, borislav.petkov@....com,
	amwang@...hat.com, ak@...ux.intel.com, eric.dumazet@...il.com,
	gregkh@...e.de, dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com,
	"Roland McGrath" <mcgrathr@...omium.org>
Subject: Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re:
 [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

On Wed, January 18, 2012 06:43, Chris Evans wrote:
>> As far as I know, we fixed all races except symlink races caused by malicious
>> code outside the jail.
>
> Are you sure? I've remembered possibly the worst one I encountered,
> since my previous e-mail to Jamie:
>
> 1) Tracee is compromised; executes fork() which is syscall that isn't allowed

How do you mean compromised? Tracees aren't trusted by definition. And fork is
allowed in our jail, we're ptracing all tasks within the jail.

> 2) Tracee traps
> 2b) Tracee could take a SIGKILL here
> 3) Tracer looks at registers; bad syscall
> 3b) Or tracee could take a SIGKILL here
> 4) The only way to stop the bad syscall from executing is to rewrite
> orig_eax (PTRACE_CONT + SIGKILL only kills the process after the
> syscall has finished)

Yes, we rewrite it to -1.

> 5) Disaster: the tracee took a SIGKILL so any attempt to address it by
> pid (such as PTRACE_SETREGS) fails.

I assume that if a task can execute system calls and we get ptrace events
for that, that we can do other ptrace operations too. Are you saying that
the kernel has this ptrace gap between SIGKILL and task exit where ptrace
doesn't work but the task continues executing system calls? That would be
a huge bug, but it seems very unlikely too, as the task is stopped and
shouldn't be able to disappear till it is continued by the tracer.

I mean, really? That would be stupid.

If true we have to work around it by disallowing SIGKILL and just sending
them ourselves within the jail. Meh.

> 6) Syscall fork() executes; possible unsupervised process now running
> since the tracer wasn't expecting the fork() to be allowed.

We use PTRACE_O_TRACEFORK (or replace it with clone and set CLONE_PTRACE
for 2.4 kernels. Yes, I check for CLONE_UNTRACED in clone calls.)

>
> All this ptrace() security headache is why vsftpd is waiting for
> Will's seccomp enhancements to hit the kernel. Then they will be used
> pronto.

How will you avoid file path races with BPF?

Greetings,

Indan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/