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

Status: RESOLVED FIXED

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

Description

[[e-mail]]

Attachment: Firefox 60.0b7-1 (72) search bug

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.

Comment 1

[[e-mail]]

Cross-posted to https://forum.snapcraft.io/t/firefox-searching-for-any-webpage-immediately-produces-gah-your-tab-just-crashed/4721

Comment 2

[[e-mail]]

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.

Comment 3

[[e-mail]]

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?)

Comment 4

[Johan Lorenzo [:jlorenzo] - On PTO, back on May 13th]

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

Comment 5

[Kestrel]

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.

Comment 6

[Johan Lorenzo [:jlorenzo] - On PTO, back on May 13th]

Great! I confirm this works on Snap, for me. We can toggle this pref on Snap, momentarily.

Comment 7

[Johan Lorenzo [:jlorenzo] - On PTO, back on May 13th]

Attachment: [mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily

Comment 8

[Kestrel]

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.

Comment 9

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

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.

Comment 10

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

Non-Snap STR:

unshare -Umr   # this starts a subshell; use it for the following commands
mount -t tmpfs tmpfs /tmp
firefox --new-instance

Comment 11

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

Attachment 8963927 [details] [diff] already landed, so I'm going to file a separate bug for the sandbox change.

Comment 12

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

https://github.com/mozilla-partners/canonical/commit/528b1911491f5ab86b7b298d3f87568b6d5f22b0

Comment 13

[[e-mail]]

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)? :)

Comment 14

[Johan Lorenzo [:jlorenzo] - On PTO, back on May 13th]

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)?

Comment 15

[Mike Kaply [:mkaply]]

Comment on attachment 8963927 [details] [diff] [review]
[mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily

Approved and merged in github.

Comment 16

[Julien Cristau [:jcristau]]

It sounds like this is fixed?

Comment 17

[Mike Kaply [:mkaply]]

Yes. It was fixed via a change in the Snap.

Comment 18

[Olivier Tilloy]

(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 19

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

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.

Comment 21

[Johan Lorenzo [:jlorenzo] - On PTO, back on May 13th]

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