1356324 - WebExtension script loaded in content via SendLoadProcessScript without moz-extension://

Status: RESOLVED INVALID

(WebExtensions :: General, enhancement)

Description

[Haik Aftandilian [:haik]]

On content startup, scripts from a WebExtension can get executed in the content process via SendLoadProcessScript/RecvLoadProcessScript where a URI is passed from parent to child. The URI isn't a moz-extension URI despite being an extension script and therefore won't be remoted by Bug 1334550 "Proxy moz-extension protocol requests to the parent process". We'll need to remote these script loads in order to remove home directory read access for sandboxing.

Comment 1

[Haik Aftandilian [:haik]]

Example content stack trace and URI:

  libsystem_kernel.dylib`__open+0xa
  XUL`nsLocalFile::OpenNSPRFileDesc(int, int, PRFileDesc**)+0x1e
  XUL`nsZipHandle::Init(nsIFile*, nsZipHandle**, PRFileDesc**)+0x33
  XUL`nsZipArchive::OpenArchive(nsIFile*)+0x24
  XUL`nsJAR::Open(nsIFile*)+0x94
  XUL`nsZipReaderCache::GetZip(nsIFile*, nsIZipReader**)+0x27d
  XUL`nsJARChannel::CreateJarInput(nsIZipReaderCache*, nsJARInputThunk**)+0x135
  XUL`nsJARChannel::Open(nsIInputStream**)+0xd7
  XUL`nsJARChannel::Open2(nsIInputStream**)+0x32
  XUL`nsMessageManagerScriptExecutor::TryCacheLoadAndCompileScript(nsAString const&, bool, bool, JS::MutableHandle<JSScript*>)+0x1a9
  XUL`nsMessageManagerScriptExecutor::LoadScriptInternal(nsAString const&, bool)+0xc4
  XUL`mozilla::dom::ProcessGlobal::LoadScript(nsAString const&)+0x63
  XUL`mozilla::dom::ContentChild::RecvLoadProcessScript(nsString const&)+0x1d
  XUL`mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&)+0x8d70
  XUL`mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&)+0x62
  XUL`mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&)+0x156
  XUL`mozilla::ipc::MessageChannel::MessageTask::Run()+0x4f
  XUL`nsThread::ProcessNextEvent(bool, bool*)+0x48f
  XUL`NS_ProcessNextEvent(nsIThread*, bool)+0x27
  XUL`mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)+0x121

Here's an example where the URI points to the AddBlockPlus extension JAR/XPI file.

  (lldb) print url
  (const nsString) $18 = (nsAString = u"jar:file:///Users/haftandilian/Library/Application%20Support/Firefox/Profiles/kt4l38wb.ext/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/lib/child/bootstrap.js?0.6098366305192885&info=%7B%22addonID%22%3A%22%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D%22%2C%22addonVersion%22%3A%222.8.2%22%2C%22addonRoot%22%3A%22jar%3Afile%3A%2F%2F%2FUsers%2Fhaftandilian%2FLibrary%2FApplication%2520Support%2FFirefox%2FProfiles%2Fkt4l38wb.ext%2Fextensions%2F%257Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%257D.xpi!%2F%22%2C%22addonName%22%3A%22adblockplus%22%2C%22application%22%3A%22firefox%22%2C%22applicationVersion%22%3A%2255.0a1%22%2C%22platform%22%3A%22gecko%22%2C%22platformVersion%22%3A%2255.0a1%22%7D")

Comment 2

[Haik Aftandilian [:haik]]

It turns out this won't happen for WebExtensions, but it's happening here in part because AdBlockPlus is not yet a WebExtension.

Given that, the question becomes if allowing read access to $PROFILE/extensions (without read access to the rest of $HOME) is sufficient until we fully transition to WebExtensions. I'll take this bug for now to try to get that resolved.

Comment 3

[Haik Aftandilian [:haik]]

This doesn't need to stay open. AddOns are dependent on being to read $PROFILE/extensions and we don't plan to remove read access to the extensions dir until legacy AddOns are no longer used.