1673770 - GMP plugins (OpenH264, EME) are broken on Fedora 34 / glibc 2.33

Status: RESOLVED FIXED

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

Description

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

Breaking this out from bug 1673202 comment #5: we have another problem with glibc mapping fstat into fstatat, because GMP processes have no broker, so they don't get the fstatat trap, meaning that fstat will fail with ENOSYS (or, on Nightly, crash with SIGSYS).

This can be seen by running any media test that uses ClearKey EME, like dom/media/test/test_eme_initDataTypes.html, with mach test; it will fail, producing errors like this:

 0:12.09 GECKO(75049) Sandbox: seccomp sandbox violation: pid 75320, tid 75320, syscall 262, args 17 140544602412045 140721852956928 4096 140544309529184 0.  Killing process.

And crash reports like this:

Crash reason:  SIGSYS
Crash address: 0x106

Thread 0 (crashed)
 0  ld-linux-x86-64.so.2 + 0x1de1e

This is from dlopen, called from GMPLoader::Load; we're still trying to load the plugin and the dynamic linker wants to fstat it. With MOZ_SANDBOX_CRASH_ON_ERROR=0 (or non-Nightly), the fstat simply fails, the library isn't loaded, and the plugin process MOZ_CRASHes; in neither case do GeckoMediaPlugins work.

This should be relatively simple to fix.

Comment 1

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

bp-a12715d3-952e-48a8-8ef6-9db3b0201025 is an independent report of this, and so far the only one I can find. When I saw it last night it had the signature [@ ld-linux-x86-64.so.2@0x1de1e ] (which, unusually for a numeric library offset, actually was informative), but once symbols arrived it was relabeled as __fstatat64 which also matches many reports of bug 1673202. To avoid confusion I won't add the latter signature to this bug.

Comment 2

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

Attachment: Bug 1673770 - Extend the handling of fstatat-as-fstat to sandboxes that don't use a file broker.

The fix for bug 1660901, to handle the subset of fstatat that is
equivalent to fstat, was incomplete: it was added to the existing
hook for the file broker, so processes that don't use a broker (like
GMP) didn't get the fix. That wasn't a problem when the only use of
that feature was in content processes via GTK, but now that glibc has
reimplemented fstat that way, it's necessary for all processes.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/086605072f76
Extend the handling of fstatat-as-fstat to sandboxes that don't use a file broker. r=gcp

Comment 4

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/086605072f76

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 9184443 [details]
Bug 1673770 - Extend the handling of fstatat-as-fstat to sandboxes that don't use a file broker.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Without this fix it could end up being impossible to watch Netflix (etc.) on ESR builds on new Linux distros. (Companion of bug 1673202, on which this depends)
• User impact if declined: Broken DRM on new distros.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Minimal code change that only activates in the specific edge case.
• String or UUID changes made by this patch:

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9184443 [details]
Bug 1673770 - Extend the handling of fstatat-as-fstat to sandboxes that don't use a file broker.

Approved for 78.6esr.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/3962fa9f3084