linux-kernel - Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox

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]

Date:	Sun, 13 Nov 2011 22:50:47 -0800
From:	Mark Seaborn <mseaborn@...omium.org>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Nix <nix@...eri.org.uk>, linux-kernel@...r.kernel.org,
	Markus Gutschke <markus@...omium.org>
Subject: Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884
 breaks the Chromium seccomp sandbox

On 13 November 2011 18:36, Andrew Lutomirski <luto@....edu> wrote:
>
> On Sun, Nov 13, 2011 at 4:40 PM, Nix <nix@...eri.org.uk> wrote:
> > With this commit installed:
> >
> > commit 5cec93c216db77c45f7ce970d46283bcb1933884
> > Author: Andy Lutomirski <luto@....EDU>
> > Date:   Sun Jun 5 13:50:24 2011 -0400
> >
> >    x86-64: Emulate legacy vsyscalls
> >
> > With CONFIG_SECCOMP set, and the Chromium seccomp sandbox compiled in
> > and enabled (which is not the default), on a system running glibc 2.12.x
> > (thus, relying on emulated vsyscalls), Chromium renderers sometimes hang
> > or abruptly abort before rendering anything (both of which show as pages
> > that never complete rendering and eventually get a Chromium kill request
> > dialog). The hang is consistent for a given page, but not all pages
> > hang. (One that *does* hang is the chrome://extensions page, so network
> > access is not the problem here.)
> >
> > vsyscall=native does not help.
> >
> > Turning off CONFIG_SECCOMP, or running Chromium with the seccomp sandbox
> > disabled, fixes it.
> >
> > I speculate that do_emulate_vsyscall() is broken, but it's hard to debug
> > the Chromium renderer sandboxing to see what's failing because the
> > multiple layers of sandboxing get in the way, as they are designed to :)
>
> I don't buy that explanation -- with vsyscall=native,
> do_emulate_vsyscall shouldn't be called at all.  I have a much simpler
> explanation: the Chromium sandbox is calling vsyscalls in seccomp
> mode, which has no business working.

I think the problem is that seccomp-sandbox attempts to patch the
vsyscall page.  It replaces the SYSCALL instructions in this page with
jumps to seccomp-sandbox's handler.  (More accurately, seccomp-sandbox
creates a patched copy of the vsyscall page.  It redirects glibc's
indirect jumps so that they go to the patched copy of the vsyscall
page instead of to the original.)  The code for this is in
patchVSystemCalls() in library.cc
(http://code.google.com/p/seccompsandbox/source/browse/trunk/library.cc).

If the vsyscall page's code no longer invokes the kernel via SYSCALL
instructions but via some other trap, seccomp-sandbox's trick will no
longer work, because it doesn't know to patch the instructions that do
this new trap.

Mark
--
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/