1621686 - Crash in [@ mozilla::InstallSyscallFilter] in socket process on kernel < 3.17

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Simon Giesecke [:sg] [he/him]]

This bug is for crash report bp-40be71c7-54f6-47d9-84e2-2912e0200311.

Top 10 frames of crashing thread:

0 libmozsandbox.so mozilla::InstallSyscallFilter security/sandbox/linux/Sandbox.cpp:236
1 libmozsandbox.so mozilla::SetThreadSandboxHandler security/sandbox/linux/Sandbox.cpp:276
2 libc-2.19.so libc-2.19.so@0x350df 
3 libxul.so event_base_loop ipc/chromium/src/third_party/libevent/event.c:1947
4 libxul.so base::MessagePumpLibevent::Run ipc/chromium/src/base/message_pump_libevent.cc
5 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
6 libxul.so base::Thread::ThreadMain ipc/chromium/src/base/thread.cc:192
7 libxul.so ThreadFunc ipc/chromium/src/base/platform_thread_posix.cc:40
8 libpthread-2.19.so start_thread /build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309
9 libc-2.19.so __clone 

The crash is due to MOZ_CRASH("seccomp+tsync failed, but kernel supports tsync");

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This is the socket process sandbox, which was recently added. The crash is on kernel 3.16, so in fact it doesn't support SECCOMP_FILTER_FLAG_TSYNC.

However… the crash messages seem to be backwards, and have been since they were added in 2016 (bug 1257361). The crash seen here should have the message about prctl, and the other one should have the message about tsync.

The problem is this item in the socket process syscall policy, which unconditionally allows prctl. For reasons explained in bug 1257361, we [intercept PR_SET_NO_NEW_PRIVS] to indicate that the thread has already applied its seccomp filter; without that, every thread will apply unboundedly many copies of the policy to itself until it runs into whatever limit the kernel imposes and fails.

(This isn't obvious except in hindsight; I wrote that code and I'd forgotten that that could happen until I started looking at this bug report.)

Simple STR for kernels ≥3.17: set MOZ_FAKE_NO_SECCOMP_TSYNC=t in the environment.

SocketProcessSandboxPolicy should instead override PrctlPolicy (and not attempt to handle prctl directly in EvaluateSyscall).

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I have a patch that seems to work.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1621686 - Fix socket process sandbox's handling of prctl to prevent crash on kernels before 3.17.

The special handling of PR_SET_NO_NEW_PRIVS can't be overridden with
Allow(); otherwise every thread in the process will repeatedly apply
copies of the policy to itself until it reaches whatever limits the
kernel imposes, and then we crash so we don't continue execution
seemingly unsandboxed. (See also bug 1257361.)

The prctl policy for the socket process is still allow-all after this
patch; it just prevents crashing the socket process on startup on
kernels before 3.17 (which don't support applying the policy atomically
to all threads).

This patch also adds a comment to try to document this failure mode.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aa459bed7de4
Fix socket process sandbox's handling of prctl to prevent crash on kernels before 3.17. r=gcp,mjf

Comment 5

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/aa459bed7de4