Closed Bug 1614535 Opened 5 years ago Closed 5 years ago

plugin-container insta-crashes on https://listen.tidal.com

Categories

(Core :: Security: Process Sandboxing, defect)

Product:
Core
Component:
Security: Process Sandboxing
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla75
Tracking Flags:
Tracking Status
relnote-firefox --- 73+
firefox-esr68 --- fixed
firefox73 --- fixed
firefox74 --- fixed
firefox75 --- fixed

People

(Reporter: emilio, Assigned: emilio)

References

Details

Crash Data

Attachments

(1 file)

Bug 1614535 - Whitelist pread64 in the common policy. r=gcp
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-release+
RyanVM
: approval-mozilla-esr68+
Details | Review

If I go to https://listen.tidal.com and play anything I get a "plugin crashed" notification. A crash report looks like:

https://crash-stats.mozilla.org/report/index/0f1b38ac-9818-4992-af4d-4c3740200211

Looks that we were killed by sigsys. Maybe ld.so blocking signals again?

No, it's Widevine being naughty and trying to use sys_pread64. Did Widevine get an update?

It looks like that's whitelisted in Content but not necessarily in the Common or GMP policy.

The stack contains glibc code so I assumed it was a glibc issue... I don't know whether it got an update or not.

FYI "Crash Address" will contain the id of the offending syscall (0x11), although the stack trace here is also quite revealing,

But wait, that changeset is from October 2019? So that wouldn't cause a sudden regression now?

Okay, so likely Widevine did get an update that makes it do an extra call to the linker, and changes in October 2019 mean that ld.so will use pread64 to implement the functionality being called. (This means not everyone who gets the Widevine update will see this problem!)

Anyway we should be able to just whitelist pread64 in the common policy I think.

I don't think I've used that website (or widewine/DRM stuff) in this computer ever before.

So I just probably haven't noticed it before.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/009245e9c470 Whitelist pread64 in the common policy. r=gcp
Crash Signature: [@__GI___pread64_nocancel]

https://hg.mozilla.org/mozilla-central/rev/009245e9c470

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox75: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla75

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

Beta/Release Uplift Approval Request

  • User impact if declined: Crash on modern Linux distros when trying to use DRM sites.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Not risky, whitelisting a syscall in a more general policy.
  • String changes made/needed:
Attachment #9125885 - Flags: approval-mozilla-beta?

Do we need this on release for 73.0.1 also?

Flags: needinfo?(emilio)

Probably?

Flags: needinfo?(emilio) → needinfo?(gpascutto)

I'd also suggest we nominate for ESR.

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

Approved for 74.0b3 for more testing. Sounds like we're still going to want release and ESR68 approval requests for 73.0.1 and 68.6esr, respectively.

Attachment #9125885 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Do we need this on release for 73.0.1 also?

It looks like glibc did a release (glibc-2.31) which has the above change in it so it is indeed reasonable for distros like Arch to take that and try to run it with release Firefox.

I'd also suggest we nominate for ESR.

Do we expect to find an 11 days old glibc on systems that run ESR? The case for ESR doesn't seem to be so clear.

Flags: needinfo?(gpascutto)

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

Beta/Release Uplift Approval Request

  • User impact if declined: Very modern rolling-release distros (Arch, Fedora Rawhide, ...) can fail to play DRM media.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Moving a whitelisted syscall to a more general policy.
  • String changes made/needed:
Attachment #9125885 - Flags: approval-mozilla-release?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #19)

Do we expect to find an 11 days old glibc on systems that run ESR? The case for ESR doesn't seem to be so clear.

As one data point, we saw almost immediate reports of bustage when the most recent SQLite update came out and it didn't work correctly with Firefox, which suggests someone somewhere is doing it :). Anyway, if the risk is low, I'd say better safe than sorry.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #19)

Do we expect to find an 11 days old glibc on systems that run ESR? The case for ESR doesn't seem to be so clear.

I'd expect it to be rare at the moment, though it looks like we have at least one possible case. I'm mostly concerned about keeping ESR 68 happy until we spin the next major release. Is it possible in the remaining lifecycle we'll see uptake of the new glibc in slower moving distros that could trip us?

Crash Signature: [@__GI___pread64_nocancel] → [@__GI___pread64_nocancel] [@ mozilla::gmp::GMPChild::ProcessingError]

when the most recent SQLite update came out and it didn't work correctly with Firefox

Firefox or Firefox ESR?

I'd expect it to be rare at the moment, though it looks like we have at least one possible case.

That machine appears to be on Linux 5.4.19-1-lts, released 2 days ago(!) so it's this weird combo of running spanking fresh kernels and glibc with a Firefox that's effectively outdated. The logic eludes me 🤷 ¯_(ツ)_/¯

Crash Signature: [@__GI___pread64_nocancel] [@ mozilla::gmp::GMPChild::ProcessingError] → [@__GI___pread64_nocancel] [@ mozilla::gmp::GMPChild::ProcessingError]

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

Fixes Linux-only crashes when trying to play encrypted content with the new Widevine plugin. Approved for 73.0.1.

Attachment #9125885 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the Firefox 73.0.1 release notes:

Fixed crashes when playing encrypted content on some Linux systems

relnote-firefox: --- → 73+
Flags: qe-verify+

Hi,

I haven't been able to reproduce the issue on Fedora 30, Ubuntu 18.04 or Windows 10 ARM-Arch build on the affected versions or the versions set as fixed using the link in the description or the link from a bug set as duplicate to this one (Bug 1615499) https://bitmovin.com/demos/drm.

However, the plugin did crash on https://shaka-player-demo.appspot.com on Arch Build Nightly 74.0a1 and then on the latest Nightly 75.0a1 when I updated it, but it does not crash if you download the latest version directly. This might be a different issue though.

Since I wasn't able to reproduce the issue, I cannot confirm the fix.

Emilio, could you please verify the fix? http://archive.mozilla.org/pub/firefox/candidates/73.0.1-candidates/

Thank you!

Flags: needinfo?(emilio)

On linuxfromscratch we will be releasing LFS-9.1 (linux-5.5.3 or later with glibc-2.31) and in BLFS-9.1 we are using ESR (so that we can keep the same version of rustc for both firefox and thunderbird) so I assume we are also affected if anyone uses tidal.com (I don't). So adding to ESR would be good.

QA Whiteboard: [qa-triaged]

Just confirmed that 73 rc doesn't crash.

Flags: needinfo?(emilio)

Please nominate this for ESR68 approval when you get a chance.

Flags: needinfo?(emilio)

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Somewhat common Linux regression.
  • User impact if declined: Widewine and co crash if a new-enough version of glibc is used.
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple sandbox rule change to avoid crashing widewine on startup.
  • String or UUID changes made by this patch: none
Flags: needinfo?(emilio)
Attachment #9125885 - Flags: approval-mozilla-esr68?

Comment on attachment 9125885 [details]
Bug 1614535 - Whitelist pread64 in the common policy. r=gcp

Fixes a possible Widevine crash with newer versions of glibc. Approved for 68.6esr.

Attachment #9125885 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: