Crash when navigating to another page immediately after initializing unity integration
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | WebApps: unity-firefox-extension |
High
|
Maxim Ermilov | ||
| | unity-firefox-extension (Ubuntu) |
Critical
|
Ken VanDine | ||
| | Quantal |
Critical
|
Unassigned | ||
| | Raring |
Critical
|
Ken VanDine | ||
Bug Description
Seb pinged me about a Firefox crash a couple of days ago. After some investigation, I've figured out a fairly trivial reproducer.
With a local test page:
1) Navigate manually to "http://
...test1.html:
<html>
<head></head>
<script>
var unity = window.
unity.
window.location = "http://
</script>
</html>
...and test2.html:
<html>
<head></head>
<script>
var unity = window.
unity.
</script>
</html>
2) Accept the integration
3) Close the browser tab
(Note, you might need to try this again after allowing the integration)
What happens is the website icon still appears in the Unity launcher after the tab is closed. Clicking it to refocus the non-existant tab will eventually cause Firefox to crash, presumably because it is calling a JS callback across ctypes which has been garbage collected. The traces will look something like this, although the top few frames will vary depending on what's now in the memory where the callback used to be:
Program received signal SIGILL, Illegal instruction.
0x00007f8a9b0000b8 in ?? ()
(gdb) bt
#0 0x00007f8a9b0000b8 in ?? ()
#1 0x00007f8a98c57ecc in ffi_call_unix64 () from /usr/lib/
#2 0x00007f8a98c45e30 in ffi_call (cif=cif@
at /build/
#3 0x00007f8a96700a9b in g_cclosure_
at /build/
#4 0x00007f8a96700140 in g_closure_invoke (closure=
#5 0x00007f8a96711550 in signal_
instance_
#6 0x00007f8a967186ab in g_signal_emitv (instance_
at /build/
#7 0x00007f8a81ade833 in unity_webapps_
#8 0x00007f8a98c57ecc in ffi_call_unix64 () from /usr/lib/
#9 0x00007f8a98c45e30 in ffi_call (cif=cif@
at /build/
#10 0x00007f8a96700a9b in g_cclosure_
marshal_
#11 0x00007f8a96700140 in g_closure_invoke (closure=
#12 0x00007f8a967112d0 in signal_
instance_
#13 0x00007f8a967194af in g_signal_
#14 0x00007f8a96719642 in g_signal_emit (instance=
#15 0x00007f8a94577b74 in on_signal_received (connection=
parameters=
#16 0x00007f8a945677f5 in emit_signal_
#17 0x00007f8a96440ab5 in g_main_dispatch (context=
#18 g_main_
#19 0x00007f8a96440de8 in g_main_
#20 0x00007f8a96440ea4 in g_main_
#21 0x00007f8a9845a226 in nsAppShell:
#22 0x00007f8a984701e1 in nsBaseAppShell:
at /build/
#23 0x00007f8a984702fa in nsBaseAppShell:
#24 0x00007f8a985f7631 in nsThread:
#25 0x00007f8a985cd666 in NS_ProcessNextE
#26 0x00007f8a98515581 in mozilla:
#27 0x00007f8a98615fef in RunHandler (this=0x7f8a9af
#28 MessageLoop::Run (this=0x7f8a9af
#29 0x00007f8a9846fbd1 in nsBaseAppShell::Run (this=0x7f8a88a
#30 0x00007f8a9834e063 in nsAppStartup::Run (this=0x7f8a88a
#31 0x00007f8a97b780cc in XREMain:
#32 0x00007f8a97b782be in XREMain::XRE_main (this=this@
at /build/
#33 0x00007f8a97b784fa in XRE_main (argc=1, argv=0x7fff6730
#34 0x00007f8a9c23c8f1 in do_main (argv=0x7fff673
#35 main (argc=<optimised out>, argv=<optimised out>) at /build/
I've seen it crash sometimes with SIGSEGV and sometimes with SIGILL. The SIGILL is probably enough to assume that this is potentially exploitable.
Related branches
- PS Jenkins bot (community): Approve (continuous-integration) on 2012-11-21
- Alexandre Abreu (community): Approve on 2012-11-20
-
Diff: 25 lines (+13/-0)1 file modifiedunity-firefox-extension/content/observer.js (+13/-0)
- PS Jenkins bot (community): Approve (continuous-integration) on 2012-11-28
- WebApps: Pending requested 2012-11-28
-
Diff: 34 lines (+21/-1)1 file modifieddebian/changelog (+21/-1)
CVE References
| Marc Deslauriers (mdeslaur) wrote : | #1 |
| Changed in unity-firefox-extension: | |
| assignee: | nobody → Maxim Ermilov (zaspire) |
| milestone: | none → 2.4.2 |
| Maxim Ermilov (zaspire) wrote : | #2 |
It happens only with ff 17
| Maxim Ermilov (zaspire) wrote : | #3 |
I belive, it is ff 17 bug.
it doesn't emit pagehide event on test1->test2 redirect.
| Changed in unity-firefox-extension: | |
| status: | New → Incomplete |
| Changed in unity-firefox-extension: | |
| assignee: | Maxim Ermilov (zaspire) → nobody |
| milestone: | 2.4.2 → none |
| Launchpad Janitor (janitor) wrote : | #4 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in unity-firefox-extension (Ubuntu Quantal): | |
| status: | New → Confirmed |
| Changed in unity-firefox-extension (Ubuntu): | |
| status: | New → Confirmed |
| Chris Coulson (chrisccoulson) wrote : | #6 |
I definitely see pagehide here in gdb for the redirect (when navigating to my test case, nsDocument:
| Changed in unity-firefox-extension: | |
| status: | Incomplete → Confirmed |
| Changed in unity-firefox-extension (Ubuntu Quantal): | |
| importance: | Undecided → High |
| Changed in unity-firefox-extension (Ubuntu Raring): | |
| importance: | Undecided → High |
| Changed in unity-firefox-extension (Ubuntu Quantal): | |
| importance: | High → Critical |
| Changed in unity-firefox-extension (Ubuntu Raring): | |
| importance: | High → Critical |
| Chris Coulson (chrisccoulson) wrote : | #7 |
Note that also doing this in a JS shell shows that pagehide fires twice when I load the testcase:
gBrowser.
| Changed in unity-firefox-extension: | |
| assignee: | nobody → Maxim Ermilov (zaspire) |
| Maxim Ermilov (zaspire) wrote : | #8 |
> Note that also doing this in a JS shell shows that pagehide fires twice when I load the testcase:
It doesn't emit pagehide during tab closing.
| Changed in unity-firefox-extension: | |
| status: | Confirmed → Fix Committed |
| Chris Coulson (chrisccoulson) wrote : | #9 |
It does here.
If you're not getting a pagehide during tab closing, then you've got an addon leaking the document
| Maxim Ermilov (zaspire) wrote : | #10 |
Can reproduce it with extension from trunk?
| Chris Coulson (chrisccoulson) wrote : | #11 |
Some comments from IRC:
<ChrisCoulson> so, the addon doesn't get pagehide because it disconnects from it the first time anybody navigates away from the first page viewed in a tab
<ChrisCoulson> in case you hadn't figured it out already, it looks like the problem with webapps is that the UnityObject's are keyed by outer window rather than inner window (and outer windows are reused between page navigations). it looks like the webapps addon assumes they are not reused...
When you navigate to a new page in a tab, this returns the same UnityObject (which has since disconnected from "pagehide"):
Then if the new page uses the Unity API, the context isn't destroyed when the tab closes, because the pagehide handler was already disconnected.
New windows are handled from the "content-
| Chris Coulson (chrisccoulson) wrote : | #12 |
https:/
1) Keys UnityObject in a weak map with an object that's tied to the inner window (I don't think it's possible to get the inner window from an outer window), so each new page gets a new object.
2) Doesn't disconnect from "pagehide" unless the window is being destroyed (using the "dom-window-
The behaviour of this API is pretty broken compared to any other DOM API though wrt page navigations though. When you navigate away from a page and it gets inserted in to the bfcache, its state should be frozen until it is recovered from the cache later on (unless it gets removed from the bfcache, in which case the page will be reloaded in a new inner window). However, the Unity API doesn't freeze the state - it actually destroys the context which means a page that is recovered from the bfcache has to reinitialize everything again.
I'm not sure if the changes I've done break anything else though. This whole thing seems really fragile.
| Marc Deslauriers (mdeslaur) wrote : | #13 |
If someone from the webapps team can please test and give an official go-ahead, I'll push this fix as a security update. Thanks!
| information type: | Private Security → Public Security |
| Víctor R. Ruiz (vrruiz) wrote : | #14 |
Regression tests
== Test 1 ==
- Step 1
1. Open Firefox
2. Go to http://
3. Accept integration test.
Expected behavior
1. Launchpad icon should appear in the Launcher.
- Step 2 (continue from step 1)
1. Close tab.
Expected behavior
1. Launchpad icon should disappear from the Launcher.
== Test 2 ==
- Step 1
1. Open Firefox
2. Go to http://
3. Accept integration test.
Expected behavior
1. BBC icon must appear in the Launcher.
- Step 2 (continue from step 1)
1. In the same tab of BBC, go to http://
Expected behavior
1. BBC icon must disappear from the Launcher and Launchpad one must show.
This has been tested with unity-firefox-
| Launchpad Janitor (janitor) wrote : | #15 |
This bug was fixed in the package unity-firefox-
---------------
unity-firefox-
* SECURITY UPDATE: denial of service and possible code execution
(LP: #1076350)
- debian/
unity-
- CVE-2012-0960
-- Marc Deslauriers <email address hidden> Thu, 22 Nov 2012 10:12:53 -0500
| Changed in unity-firefox-extension (Ubuntu Quantal): | |
| status: | Confirmed → Fix Released |
| Launchpad Janitor (janitor) wrote : | #16 |
This bug was fixed in the package unity-firefox-
---------------
unity-firefox-
* SECURITY UPDATE: denial of service and possible code execution
(LP: #1076350)
- debian/
unity-
- CVE-2012-0960
-- Marc Deslauriers <email address hidden> Thu, 22 Nov 2012 10:44:07 -0500
| Changed in unity-firefox-extension (Ubuntu Raring): | |
| status: | Confirmed → Fix Released |
| Marc Deslauriers (mdeslaur) wrote : | #17 |
The fix for this got reverted in the raring 2.4.2-0ubuntu1 upload. Reopening bug.
| Changed in unity-firefox-extension (Ubuntu Raring): | |
| status: | Fix Released → Confirmed |
| assignee: | nobody → Ken VanDine (ken-vandine) |
| Changed in unity-firefox-extension: | |
| importance: | Undecided → High |
| Marc Deslauriers (mdeslaur) wrote : | #18 |
Actually, the patch is clearly in the raring 2.4.2-0ubuntu1 package. I'm not sure why I though the fix got reverted. Apologies for the confusion. Closing bug.
| Changed in unity-firefox-extension (Ubuntu Raring): | |
| status: | Confirmed → Fix Released |
Hello Chris, or anyone else affected,
Accepted unity-firefox-
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
| tags: | added: verification-needed |
| Víctor R. Ruiz (vrruiz) wrote : | #20 |
Regression tests
== Test 1 ==
- Step 1
1. Open Firefox
2. Go to http://
3. Accept integration test.
Expected behavior
1. Launchpad icon should appear in the Launcher.
- Step 2 (continue from step 1)
1. Close tab.
Expected behavior
1. Launchpad icon should disappear from the Launcher.
== Test 2 ==
- Step 1
1. Open Firefox
2. Go to http://
3. Accept integration test.
Expected behavior
1. BBC icon must appear in the Launcher.
- Step 2 (continue from step 1)
1. In the same tab of BBC, go to http://
Expected behavior
1. BBC icon must disappear from the Launcher and Launchpad one must show.
Tested with Firefox 19.0+build1-
This is CVE-2012-0960