1543858 - sandbox causes crash when attempting Vorbis decoding on RDD

Status: RESOLVED FIXED

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

Description

[Michael Froman [:mjf]]

Attachment: enable vorbis on rdd and make test_playback.html run just one .ogg file

While trying to verify behavior I was seeing on macOS, I tried turning on Vorbis decoding on RDD on linux. On RDD initializing the Vorbis decoder causes an sandbox exception:

1:19.46 GECKO(11475) Sandbox: seccomp sandbox violation: pid 11698, tid 11705, syscall 99, args 139971286315296 2048 139971796575892 88 0 12335137464869716225. Killing
process.
1:19.46 GECKO(11475) Sandbox: crash reporter is disabled (or failed); trying stack trace:
1:19.52 GECKO(11475) Sandbox: frame #01: __restore_rt (sigaction.c:?)
1:21.93 GECKO(11475) Sandbox: frame #02: __sysinfo (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/syscall-template.S:78)
1:21.93 GECKO(11475) Sandbox: frame #03: __GI___get_phys_pages (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/getsysstats.c:323)
1:21.93 GECKO(11475) Sandbox: frame #04: posix_sysconf (/build/glibc-OTsEL5/glibc-2.27/posix/../sysdeps/posix/sysconf.c:634)
1:21.93 GECKO(11475) Sandbox: frame #05: __GI___qsort_r (/build/glibc-OTsEL5/glibc-2.27/stdlib/msort.c:189)
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9a in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9b in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9c in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9a in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9b in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9c in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
1:39.87 GECKO(11475) Sandbox: frame #06: vorbis_book_init_decode (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_sharedbook.c:358)
1:39.88 GECKO(11475) Sandbox: frame #07: _vds_shared_init (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_block.c:240)
1:39.89 GECKO(11475) Sandbox: frame #08: vorbis_synthesis_init (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_block.c:709)
1:39.97 GECKO(11475) Sandbox: frame #09: mozilla::VorbisDataDecoder::Init() (/home/mfroman/mozilla/moz-central/dom/media/platforms/agnostic/VorbisDecoder.cpp:87)
1:39.98 GECKO(11475) Sandbox: frame #10: mozilla::RemoteDecoderParent::RecvInit() (/home/mfroman/mozilla/moz-central/dom/media/ipc/RemoteDecoderParent.cpp:44)
1:40.01 GECKO(11475) Sandbox: frame #11: mozilla::PRemoteDecoderParent::OnMessageReceived(IPC::Message const&) (/home/mfroman/mozilla/obj/deb/ipc/ipdl/PRemoteDecoderParent.cpp:223)
1:40.02 GECKO(11475) Sandbox: frame #12: mozilla::PRemoteDecoderManagerParent::OnMessageReceived(IPC::Message const&) (/home/mfroman/mozilla/obj/deb/ipc/ipdl/PRemoteDecoderManagerParent.cpp:137)
1:40.06 GECKO(11475) Sandbox: frame #13: mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) (/home/mfroman/mozilla/moz-central/ipc/glue/MessageChannel.cpp:2151)
1:41.58 GECKO(11475) Sandbox: frame #14: mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) (Unified_cpp_ipc_glue1.cpp:?)
1:41.61 GECKO(11475) Sandbox: frame #15: mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) (Unified_cpp_ipc_glue1.cpp:?)
1:41.62 GECKO(11475) Sandbox: frame #16: mozilla::ipc::MessageChannel::MessageTask::Run() (/home/mfroman/mozilla/moz-central/ipc/glue/MessageChannel.cpp:1969)
1:41.66 GECKO(11475) Sandbox: frame #17: nsThread::ProcessNextEvent(bool, bool*) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThread.cpp:1182)
1:41.67 GECKO(11475) Sandbox: frame #18: NS_ProcessNextEvent(nsIThread*, bool) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThreadUtils.cpp:486)
1:41.68 GECKO(11475) Sandbox: frame #19: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (/home/mfroman/mozilla/moz-central/ipc/glue/MessagePump.cpp:334)
1:41.70 GECKO(11475) Sandbox: frame #20: MessageLoop::RunInternal() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:315)
1:41.72 GECKO(11475) Sandbox: frame #21: MessageLoop::RunHandler() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:309)
1:41.73 GECKO(11475) Sandbox: frame #22: MessageLoop::Run() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:290)
1:41.74 GECKO(11475) Sandbox: frame #23: nsThread::ThreadFunc(void*) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThread.cpp:456)
1:41.81 GECKO(11475) Sandbox: frame #24: _pt_root (/home/mfroman/mozilla/moz-central/nsprpub/pr/src/pthreads/ptthread.c:204)
1:41.81 GECKO(11475) Sandbox: frame #25: start_thread (/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
1:41.81 GECKO(11475) Sandbox: frame #26: __GI___clone (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97)
1:41.81 GECKO(11475) Sandbox: frame #27: ??? (???:???)
1:41.81 GECKO(11475) Sandbox: end of stack.

I'll include the patch needed to enable vorbis on linux (on everything really, just for this test) and to trim a mochitest down to a reasonably quick test case.

The only time I see the full stack of from the sandbox is running under rr like this:
./mach mochitest --debugger=rr --keep-open=false dom/media/test/test_playback.html

If I run outside of rr, I only see the first line from above:
1:19.46 GECKO(11475) Sandbox: seccomp sandbox violation: pid 11698, tid 11705, syscall 99, args 139971286315296 2048 139971796575892 88 0 12335137464869716225. Killing
process.

Comment 1

[Michael Froman [:mjf]]

Jed, any thoughts here?

Comment 2

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

glibc's qsort calls sysconf to find out how much RAM there is in case the input is big enough that it matters. For libvorbis' tables it's probably not an issue, but it does it anyway. For _SC_PHYS_PAGES, this uses the sysinfo system call.

It should be enough to add case __NR_sysinfo: return Error(EPERM); to SandboxPolicyCommon::EvaluateSyscall; qsort falls back to assuming there's adequate RAM.

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Comment 3

[Michael Froman [:mjf]]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Setting MOZ_CRASHREPORTER_DISABLE doesn't seem to have any effect on getting the full sandbox stack trace when not in rr.

Comment 4

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

(In reply to Michael Froman [:mjf] from comment #3)

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Setting MOZ_CRASHREPORTER_DISABLE doesn't seem to have any effect on getting the full sandbox stack trace when not in rr.

But it is writing a minidump, and if I set things up correctly (set $MINIDUMP_STACKWALK to the path to minidump_stackwalk from my local build of Breakpad and run ./mach buildsymbols first) then ./mach test will unwind it… except that it doesn't show anything inside libc (and in theory it's affected by bug 1310314, but qsort_r has a frame pointer because it uses alloca).

It looks like the way the sandbox hooks into the crash reporter isn't affected by the crash reporter's normal runtime enabling/disabling, and I don't know if it ever has. (It was originally written for B2G where that wasn't as much of an issue, and hasn't been looked at much in the meantime.) I'll file a bug.

Comment 5

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

I have a patch and the test is failing with failed | spacestorm-1000Hz-100ms.ogg duration (0.256) should be around 0.099 now, but no other sandbox problems.

Comment 6

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

Attachment: Bug 1543858 - Adjust Linux sandbox policies to tolerate glibc's qsort.

Comment 7

[Michael Froman [:mjf]]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #5)

I have a patch and the test is failing with failed | spacestorm-1000Hz-100ms.ogg duration (0.256) should be around 0.099 now, but no other sandbox problems.

Excellent, thank you! That is the failure that led me to try things on linux to begin with, so expected to some degree.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/01d9700306a4
Adjust Linux sandbox policies to tolerate glibc's qsort. r=gcp

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/01d9700306a4