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 18:36:46 -0800
From:	Andrew Lutomirski <luto@....edu>
To:	Nix <nix@...eri.org.uk>
Cc:	linux-kernel@...r.kernel.org, mseaborn@...omium.org
Subject: Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884
 breaks the Chromium seccomp sandbox

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.

The attached patch (in vsyscall=native mode) should help diagnose
exactly what's wrong.  But I wouldn't be surprised if you can trigger
the exact same failure on older kernels by doing

# echo acpi_pm >/sys/devices/system/clocksource/clocksource0/current_clocksource

and then going to the broken page.  Just because vgettimeofday
sometimes doesn't issue a syscall (and is therefore not caught by the
seccomp code) doesn't mean it never issues a syscall.

If the crash is in vtime instead, then there's an argument to be made
that time and vtime should be allowed in seccomp mode, in which case
it's an easy change to make.  But if I'm right, I think that Chromium
should stop using vsyscalls from inside the sandbox.

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