Closed Bug 1543858 Opened 3 years ago Closed 3 years ago

sandbox causes crash when attempting Vorbis decoding on RDD

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: mjf, Assigned: jld)

References

Details

Crash Data

Attachments

(2 files)

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.

Jed, any thoughts here?

Flags: needinfo?(jld)

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?

Assignee: nobody → jld
Flags: needinfo?(jld)
Priority: -- → P1

(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.

(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.

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.

(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.

Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01d9700306a4
Adjust Linux sandbox policies to tolerate glibc's qsort. r=gcp
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Duplicate of this bug: 1547768
Crash Signature: [@ libc-2.28.so@0xfa497]
You need to log in before you can comment on or make changes to this bug.