Closed Bug 1449594 Opened 4 years ago Closed 4 years ago

[snap] Searching for any webpage immediately produces 'Gah. Your tab just crashed.'

Categories

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

60 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 - fixed
firefox61 --- fixed

People

(Reporter: ads200002, Assigned: u504868)

References

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

```
$ snap info firefox
tracking:  edge
installed:   60.0b7-1 (72) 201MB -
$ snap version
snap    2.32.1
snapd   2.32.1
series  16
ubuntu  17.10
kernel  4.13.0-37-generic
$ snap info core
tracking:  beta
installed:   16-2.32.1              (4327) 86MB core
```

Ran the 60.0b7-1 (72) snap in edge by using `snap run firefox` (you can install it by installing snapd and then `snap install firefox --edge`) and typed `google.com` into the address bar.


Actual results:

Got the 'Gah. Your tab just crashed.' page and the output in Terminal which is attached, or see this link: https://paste.ubuntu.com/p/NtDG5xd2zX/


Expected results:

The website should have loaded.
Firefox has the avahi-observe, browser-support, camera, cups-control, desktop, desktop-legacy, gsettings, home, network, opengl, pulseaudio, screen-inhibit-control, unity7, upower-observe, x11 interface connections and I'm using the Ubuntu on Xorg session.

This bug is not reproducible in 59.0.2-1 (71) which is in the stable channel.
I think the bug affects  60.0b6-1 (70) (which is in the beta channel) as well (I wish I could edit comments)...though in that typing an address and pressing enter does nothing (also happens in revision 72 I think, but if you play around with it for long enough you may be able to reproduce this particular bug). Also the default home page isn't loading (probably closely related to this bug so I won't file a new one?)
Tracking request: Perma-crash on the newly released snap format. This was confirmed by Canonical. This affects beta but not the current release. 

Asking for a regression window to know what beta introduced the crash. To do so, run:
> snap install firefox
> snap refresh --revision XXX firefox

Replace XXX by the numbers belows
> #70 => 60.0b6-1
> #69 => 60.0b4-1
> #68 => 59.0.1-1 => It looks like 60.0b5 wasn't pushed to the Snap store.
> #67 => 60.0b3-1

If you need to verify 60.b5, you can download the snap file here[1] and run:
> snap install --dangerous <file>

[1] https://queue.taskcluster.net/v1/task/E2zOZ3o-Rw2FyiIPIE6suw/runs/0/artifacts/public/build/firefox-60.0b5.snap
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: snappy
Errors on Ubuntu 17.10 with Wayland:

> Failed to connect to Mir: Failed to connect to server socket: No such file or directory
> Unable to init server: Could not connect: Connection refused
> (/snap/firefox/x1/firefox:22779): Gtk-WARNING **: cannot open display: :0

> TypeError: browser.contentWindow is null

Solved by setting media.cubeb.sandbox = false and restarting.

Possibly regressed by Bug 1428952.
Blocks: 1428952
Great! I confirm this works on Snap, for me. We can toggle this pref on Snap, momentarily.
Bug 1126437 increased security.sandbox.content.level from 3 to 4 in FF60 and made it fall back to level 3 internally when media.cubeb.sandbox = false. It doesn't crash when the content sandbox is level 3 with cubeb sandbox enabled so it appears the level 4 content sandbox is the real regressor.
Blocks: 1126437
No longer blocks: 1428952
Component: Untriaged → Security: Process Sandboxing
OS: Unspecified → Linux
Product: Firefox → Core
What's going on here is more or less what's described in [1], but I forgot something: that situation can also happen if the browser is run with access to the X server's network namespace but without access to /tmp/.X11-unix.  (I mentioned this in one of the commits for bug 1440206, but apparently didn't realize all of the implications.)

And that's what's happening here: the application is run in the root network namespace[2], but it's in a separate mount namespace with a private /tmp.

(Wayland doesn't matter for this — Firefox is still using X11 via Xwayland, which for this purpose behaves like regular Xorg.  A native Wayland port of Firefox is being worked on, but judging by the bug traffic it's a work in progress.)

The ideal solution would be to bind-mount /tmp/.X11-unix into the Snap container.  However, I can work around this by not unsharing the network namespace if X11 is in use and that directory doesn't exist; that way we can still block socket APIs with seccomp-bpf.


[1] https://searchfox.org/mozilla-central/rev/b80994a43e5d92c2f79160ece176127eed85dcc9/security/sandbox/linux/launch/SandboxLaunch.cpp#89-95

[2] Which means that the attack described in https://mjg59.dreamwidth.org/42320.html still works, although with Xwayland the scope seems to be limited to other X11 clients.
Non-Snap STR:

unshare -Umr   # this starts a subshell; use it for the following commands
mount -t tmpfs tmpfs /tmp
firefox --new-instance
Assignee: nobody → jld
Priority: -- → P1
Attachment 8963927 [details] [diff] already landed, so I'm going to file a separate bug for the sandbox change.
https://github.com/mozilla-partners/canonical/commit/528b1911491f5ab86b7b298d3f87568b6d5f22b0
Assignee: jld → jlorenzo
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Can Canonical/Mozilla rebuild the 60.0b8 snap as 60.0b8-2 or should we wait for 60.0b9 (how often are betas released anyway, I can't find docs on that)? :)
60.0b9 was built yesterday. I just made the snap available on the beta channel. For the record, we release betas twice a week, generally on Tuesdays and Thursdays.

Ken, do you know whether we can do something about /tmp/.X11-unix in a snap (comment 9)?
Flags: needinfo?(ken.vandine)
Comment on attachment 8963927 [details] [diff] [review]
[mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily

Approved and merged in github.
Attachment #8963927 - Flags: review?(mozilla) → review+
It sounds like this is fixed?
Yes. It was fixed via a change in the Snap.
See Also: → 1448255
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #9)
> The ideal solution would be to bind-mount /tmp/.X11-unix into the Snap
> container.  However, I can work around this by not unsharing the network
> namespace if X11 is in use and that directory doesn't exist; that way we can
> still block socket APIs with seccomp-bpf.

There are no current plans to mount /tmp/.X11-unix into the snap's mount namespace, since X is typically accessed via an abstract socket. That doesn't mean that it cannot be discussed and considered, though. The topic was recently mentioned in a forum thread (https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580), so maybe add to that thread to make the case for it?
Comment on attachment 8963927 [details] [diff] [review]
[mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily

Review of attachment 8963927 [details] [diff] [review]:
-----------------------------------------------------------------

For future reference, it would have been better to change security.sandbox.content.level.  The media.cubeb.sandbox pref controls audio remoting, and flipping it means you're using a different audio code path which isn't normally used in versions ≥60, isn't being regularly tested, and has already had some bit-rot problems.

But there's not much point in changing it now, because with the patch from bug 1450740 it should be possible to just revert this.
Attachment #8963927 - Attachment is patch: true
Attachment #8963927 - Attachment mime type: text/x-github-pull-request → text/plain
Attachment #8963927 - Flags: review-
Duplicate of this bug: 1448255

Clearing needinfo due to inactivity. Bug has been fixed since then :)

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