Open Bug 1725481 Opened 3 years ago Updated 5 months ago

Widevine plugin DLL can't be loaded with S Mode restrictions

Categories

(Firefox :: Installer, defect, P3)

Product:
Firefox
Component:
Installer
Type:
defect

Tracking

()

People

(Reporter: agashlin, Unassigned)

References

(Blocks 1 open bug)

Details

Following the procedure for "Production mode policy with self-signed apps" in Test your Windows app for Windows 10 in S mode (the pfx, cer, and p7b files below come from the link here).

Steps to reproduce:

  1. Produce an MSIX signed with AppxTestRootAgency.pfx

  • Fetch a Nightly zip like this one

  • Repackage as MSIX, specifying a the test publisher:

./mach repackage msix --input firefox-93.0a1.en-US.win64.zip --channel nightly --arch x86_64 --publisher "CN=Appx Test Root Agency Ex" --output firefox.msix
  • Sign (easiest to do this directly with signtool):
signtool /fd SHA256 /f AppxTestRootAgency.pfx firefox.msix
  1. Set up a Windows 10 Pro VM to simulate S Mode restrictions

  • Install AppxTestRootAgency.cer to the local machine root store

  • Copy SiPolicy_DevModeEx_Enforced.p7b to C:\Windows\System32\CodeIntegrity\SIPolicy.P7B

  • Reboot

  1. Install firefox.msix on the VM (should work with just a double click to launch App Installer)

  2. Visit https://bitmovin.com/demos/drm

Above the video will be a message "Detected [Firefox logo], using Widevine". Attempting to play the video will churn for a while and fail, with these errors in the Code Integrity event log:

Code Integrity determined that a process (\Device\HarddiskVolume2\Program Files\WindowsApps\Mozilla.Nightly_93.2021.812.1020_x64__8x64rcfmpem5g\VFS\ProgramFiles\Nightly Package Root\plugin-container.exe) attempted to load \Device\HarddiskVolume2\Users\Adam\AppData\Local\Packages\Mozilla.Nightly_8x64rcfmpem5g\LocalCache\Roaming\Mozilla\Firefox\Profiles\fwhzwvhe.default-default\gmp-widevinecdm\4.10.2209.1\widevinecdm.dll that did not meet the Custom 1 signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076}).

Code Integrity determined that a process (\Device\HarddiskVolume2\Program Files\WindowsApps\Mozilla.Nightly_93.2021.812.1020_x64__8x64rcfmpem5g\VFS\ProgramFiles\Nightly Package Root\plugin-container.exe) attempted to load \Device\HarddiskVolume2\Users\Adam\AppData\Local\Packages\Mozilla.Nightly_8x64rcfmpem5g\LocalCache\Roaming\Mozilla\Firefox\Profiles\fwhzwvhe.default-default\gmp-widevinecdm\4.10.2209.1\widevinecdm.dll that did not meet the Custom 1 signing level requirements.

I think that this is an accurate simulation of what would happen in S Mode.

S Mode policy requires every binary to be signed by the Microsoft Store (the SiPolicy_DevModeEx_Enforced policy extends this to the test cert), but the DLL isn't signed, so the plugin process crashes itself (sample crash in mozilla::gmp::GMPChild::ProcessingError). Normally these signatures would be provided in the package in a Code Integrity catalog (AppxMetadata/CodeIntegrity.cat, though see bug 1725446), but because we download the Widevine DLL separately it has only Google's signature, insufficient for this policy.

If Google signed their binaries in a different way, could this be compatible? Would that be possible with their binaries living outside the store?

As long as there is a signature from the store present, then that should work. The policy is specific to Microsoft's store signatures, but maybe we or Google could get them to sign it independently. Maybe it could be submitted in a separate package and we could use that somehow (there are a few apps on the store that just provide codecs), or extract the signature from that. I don't know if we have the rights, but Google might be able to try.

I also don't know how the signature would be provided. Maybe it could be attached to the DLL like a normal Authenticode signature. But it may need to be in a separate Code Integrity catalog, and possibly those catalogs need to be installed somehow (this suggests they need to be installed in system32, but that might only be for OS-level binaries).

Aiui, we need to sign the non-blessed files with the production widevine key, and the blessed files with the production widevine key using the blessed flag.

Are these signatures in the file we're testing? Would Microsoft's signatures overwrite these signatures?

The Microsoft Store signatures are in a separate Code Integrity catalog file. It remains to be seen whether we can get a hold of that without installing a package. (I don't know anything about the widevine key.)

Ok. Maybe we should sign the msix with the production widevine key before sending to Microsoft?

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #6)

Ok. Maybe we should sign the msix with the production widevine key before sending to Microsoft?

As far as I know, we are. MSIX's are created after repackage (eg: https://firefox-ci-tc.services.mozilla.com/tasks/CH7VlQkuT0S2JjSP2X9vZQ), which depends on build-signing, which takes care of the widevine signing.

Setting severity to S2 because this blocks critical functionality and AFAIK no workaround exists.

Severity: -- → S2

:bryce: it looks like we may be able to detect whether we're running under S Mode (Bug 1737177). If we can dynamically determine if these library loads are going to fail, can you suggest how difficult it would be to avoid crashing? Is there any blessed/official way to disable this DRM business that we could use which would hopefully have UX explaining what is happening? I know there is an EME-free repack, and it looks like [media.eme.enabled=false]
(https://github.com/mozilla-partners/mozilla-EME-free/blob/a8942ed5b8c0e802062d809916d367b9d534567a/desktop/mozilla-EME-free/distribution/distribution.ini#L11) may be what we're looking for. Have you any other suggestions?

Group: mozilla-employee-confidential
Flags: needinfo?(bvandyk)

The media.eme.enabled=false pref can be used to turn off DRM and will stop loads being attempted. However, with just that pref, if a user loads a page with DRM in it our current workflow will show a notification prompting the user to enable DRM.

If we're using just prefs, we can hide widevine pretty well via

  • browser.eme.ui.enabled=false
  • media.gmp-widevinecdm.visible=false
  • media.gmp-widevinecdm.enabled=false

A subset of those may get the job done, but I believe those are the prefs that result from a non-EME build. If we want to go beyond prefs I think we can still build without EME, but it sounds like that's not the goal here (if we want to detect at runtime).

I don't think we have any UX right now to support a "you're in a mode where DRM can't be used" notification. What we have is more "do you want to turn DRM on?"

If we can detect S mode, then we can certainly engineer such a notification with some help from UX folks.

Flags: needinfo?(bvandyk)
Priority: -- → P3

Because we're not shipping to S mode users severity can be lowered.

Severity: S2 → S3

Are you certain? Firefox was recently added to the Microsoft Store, so I would have expected that this would become more important.

Flags: needinfo?(bhearsum)

(In reply to BEEDELLROKEJULIANLOCKHART from comment #12)

Are you certain? Firefox was recently added to the Microsoft Store, so I would have expected that this would become more important.

Yes -- we have explicitly turned off Windows S Mode support for our Microsoft Store products because of this issue.

When we have a viable workaround we intend to re-enable it, though.

Flags: needinfo?(bhearsum)
You need to log in before you can comment on or make changes to this bug.