Daniel Veditz [:dveditz] Reporter
	Description • 9 years ago

From winning Pwn2Own entry by Mariusz Mlynski [2/2]:

-----------------------
2. PRIVILEGE ESCALATION
-----------------------

This is an extension of the cross-origin bypass vulnerability. The internal pdf viewer in Firefox executes with the "resource://pdf.js/web/viewer.html" security principal. It's unprivileged, but the handling of "resource:" principals with respect to loading permissions is incorrect, as documented in the source code:


>>>>>>>>>>>>>>>>>>>>>> /caps/nsScriptSecurityManager.cpp >>>>>>>>>>>>>>>>>>>>>>>
NS_IMETHODIMP
nsScriptSecurityManager::CheckLoadURIWithPrincipal(nsIPrincipal* aPrincipal,
                                                   nsIURI *aTargetURI,
                                                   uint32_t aFlags)
{
(...)

    // Check for chrome target URI
    rv = NS_URIChainHasFlags(targetBaseURI,
                             nsIProtocolHandler::URI_IS_UI_RESOURCE,
                             &hasFlags);
    NS_ENSURE_SUCCESS(rv, rv);
    if (hasFlags) {
        (...)

        // resource: and chrome: are equivalent, securitywise
        // That's bogus!!  Fix this.  But watch out for
        // the view-source stylesheet?
        bool sourceIsChrome;
        rv = NS_URIChainHasFlags(sourceBaseURI,
                                 nsIProtocolHandler::URI_IS_UI_RESOURCE,
                                 &sourceIsChrome);
        NS_ENSURE_SUCCESS(rv, rv);
        if (sourceIsChrome) {
            return NS_OK;
        }
        if (reportErrors) {
            ReportError(nullptr, errorTag, sourceURI, aTargetURI);
        }
        return NS_ERROR_DOM_BAD_URI;
    }

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


The nsIProtocolHandler::URI_IS_UI_RESOURCE flag is set for chrome:, resource:, and moz-icon: URIs. They're all free to load other URIs with this flag, including chrome-privileged pages under "chrome:". This bogus treatment of resource: principals paves the way for a privilege escalation in the event of a cross-origin bypass, such as the one described above. The attacker can use the session history confusion to execute code in the context of the pdf viewer and then re-use the said attack to compromise a privileged page, allowing for javascript code execution with the system principal.

	Daniel Veditz [:dveditz] Reporter
	Comment 1 • 9 years ago

This one might be a little more complete (req's common.js from the .zip file).

	Bobby Holley (:bholley)
	Comment 2 • 9 years ago

bz is the expert on loading permissions. Boris, let me know if you have the cycles to take this, or whether you want me to go take a crack at it. I can do so tomorrow morning, if needed.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 3 • 9 years ago

So just to be clear, this bug on its own is not exploitable without having some way to violate same-origin policy (in this case, bug 1144988 was used).

Also to be clear, there are various cases where we simply allow chrome:// bits through CheckLoadURI; for example any case that uses ALLOW_CHROME plus has the URI whitelisted in the chrome registry.

The important thing for the exploit, in addition to bug 1144988, was that we allowed loading the chrome:// URI in an iframe.

So I think the simplest/safest fix here is to change the "allow loading chrome:// from resource://" bit to only happen when ALLOW_CHROME is set.  That is, ALLOW_CHROME would allow loading any chrome:// URI from a resource:// URI, not just whitelisted ones.

A more daring fix, with more potential addon fallout, would be to simply drop the "resource:// is allowed to load chrome://" bit entirely.  I'm fairly certain that nothing in Firefox depends on it.  We _may_ have dependencies on chrome:// loading resource:// (e.g. the XML prettyprint stylesheet and maybe the viewsource stylesheet).  Would be worth checking.

The "more daring" option might be able to prevent some sort of addon fingerprinting things, maybe, but is really not needed to prevent the whole "script execution with system principal" thing.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 9 years ago

This is the m-c patch, but also applies to aurora and beta

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 5 • 9 years ago

I filed bug 1145314 on the "more daring fix" bit.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 7 • 9 years ago

Comment on attachment 8580220 [details] [diff] [review]
Be a bit more restrictive about when a URI_IS_UI_RESOURCE source is allowed to link to a URI_IS_UI_RESOURCE URI that doesn't have the same scheme

Approval Request Comment
[Feature/regressing bug #]: None; this has been around for a while.
[User impact if declined]: Some possibly-fishy loads can be performed, but on its
   own nothing fatal.
[Describe test coverage new/current, TreeHerder]: Test coverage is probably
   somewhat lacking....
[Risks and why]: The main risk is breaking parts of the Firefox UI or addons. 
   Specifically, the most likely breakage is resource:// URLs loading subframes
   that contain chrome:// URLs.  I expect this risk to be fairly low, which is
   the only reason I'm asking for approvals at all.
[String/UUID change made/needed]: None

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 9 years ago

Comment on attachment 8580223 [details] [diff] [review]
Patch for esr31; identical except for the filename

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
   Unrated so far, so requesting just in case.
User impact if declined: See comment 7
Fix Landed on Version: 39
Risk to taking this patch (and alternatives if risky): See comment 7
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 9 • 9 years ago

Comment on attachment 8580220 [details] [diff] [review]
Be a bit more restrictive about when a URI_IS_UI_RESOURCE source is allowed to link to a URI_IS_UI_RESOURCE URI that doesn't have the same scheme

[Security approval request comment]
How easily could an exploit be constructed based on the patch?  Not particularly easily.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?  I think the actual code change pretty much paints as much of a bulls-eye as the comments do, though the comments do point out that document loading is really the relevant thing here.

Which older supported branches are affected by this flaw?  All of them.  Here's the same code in a slightly old branch: http://mxr.mozilla.org/aviarybranch/source/caps/src/nsScriptSecurityManager.cpp#1290

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?  This should be pretty easy to backport, even to aviarybranch.  ;)

How likely is this patch to cause regressions; how much testing does it need?  This is the fun bit.  The regression risk is definitely nonzero, especially for addons....  The more testing we can get, the better.

	Al Billings [:abillings - ex-MoCo]
	Comment 10 • 9 years ago

Comment on attachment 8580220 [details] [diff] [review]
Be a bit more restrictive about when a URI_IS_UI_RESOURCE source is allowed to link to a URI_IS_UI_RESOURCE URI that doesn't have the same scheme

sec-approval+ and approval for aurora and beta. I'll leave release approval for the release management team.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 11 • 9 years ago

[Tracking Requested - why for this release]:

	Bobby Holley (:bholley)
	Comment 12 • 9 years ago

Comment on attachment 8580220 [details] [diff] [review]
Be a bit more restrictive about when a URI_IS_UI_RESOURCE source is allowed to link to a URI_IS_UI_RESOURCE URI that doesn't have the same scheme

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

Thanks for writing this up! r=bholley with comments addressed.

::: caps/nsScriptSecurityManager.cpp
@@ +750,5 @@
>      if (hasFlags) {
>          if (aFlags & nsIScriptSecurityManager::ALLOW_CHROME) {
> +            // Allow a URI_IS_UI_RESOURCE source to link to a URI_IS_UI_RESOURCE
> +            // target if ALLOW_CHROME is set (i.e. we're not loading a
> +            // document).

Please explain this in a bit more detail, as you did over IRC - ALLOW_CHROME is a flag that we pass on all loads _except_ docshell loads (since docshell loads run the loaded content with its origin principal). So we're effectively allowing resource://, chrome://, and moz-icon:// source URIs to load resource://, chrome://, and moz-icon:// files, so long as they're not loading it as a document.

@@ +764,3 @@
>              if (!targetScheme.EqualsLiteral("chrome")) {
> +                // for now don't change behavior for resource: or moz-icon: and
> +                // just allow them.

Nit - I think this should go at the top of the block, then the sourceIsUIResource stuff, then the whitelist stuff.

@@ +784,5 @@
>          }
>          return NS_ERROR_DOM_BAD_URI;
>      }
>  
>      // Check for target URI pointing to a file

There's a similar "that's bogus" comment below here. Is there anything we could do for file:// loads? I suspect not really, since file:// URIs don't have privileged principals, and the dangers of loading them are basically equivalent whether or not they're loaded as a document.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 13 • 9 years ago

I wont' be able to land this until 4-5 hours from now.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 14 • 9 years ago

(In reply to Not doing reviews right now from comment #13)
> I wont' be able to land this until 4-5 hours from now.

I take it that the patch is ready but you're just unavailable to land. (We can find someone else to land so that we can gtb.) Can you please confirm?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 15 • 9 years ago

Oh, sorry.  Patch needs the review comments applied too.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 16 • 9 years ago

bholley - Can you take care of applying your review comments and attaching a new patch while bz is out?

	Daniel Veditz [:dveditz] Reporter
	Comment 17 • 9 years ago

bholley and bz's comments have convinced me that this is not exploitable _by_itself_ without a SOP violation so I'm lowering the severity, but that doesn't really lower its _importance_ since it's part of a privilege escalation chain.

Add-ons do so many crazy things I can't say none of them use the functionality this blocks. Yeah, maybe Firefox 38 is safer to get feedback and give add-ons time to re-write around it.

	Bobby Holley (:bholley)
	Comment 18 • 9 years ago

ESR31 patch can land as-is.

	Bobby Holley (:bholley)
	Comment 19 • 9 years ago

(In reply to Daniel Veditz [:dveditz] from comment #17)
> bholley and bz's comments have convinced me that this is not exploitable
> _by_itself_ without a SOP violation so I'm lowering the severity, but that
> doesn't really lower its _importance_ since it's part of a privilege
> escalation chain.
> 
> Add-ons do so many crazy things I can't say none of them use the
> functionality this blocks. Yeah, maybe Firefox 38 is safer to get feedback
> and give add-ons time to re-write around it.

This patch is relatively "safe", at least compared to the other alternatives. Putting it in 37 seems like a good compromise to me IMO - it's probably fine, but we want at least the chance to respin before shipping it to our entire user base.

	Daniel Veditz [:dveditz] Reporter
	Comment 20 • 9 years ago

I'm happier trying for 37 than waiting 8 weeks for 38

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 21 • 9 years ago

Comment on attachment 8580297 [details] [diff] [review]
Be a bit more restrictive about when a URI_IS_UI_RESOURCE source is allowed to link to a URI_IS_UI_RESOURCE URI that doesn't have the same scheme.  r=bholley

Carrying forward Aurora and Beta approval. We're not going to take this fix on release.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 22 • 9 years ago

checkin-needed as bz can't land now and I don't see bholley on irc.

	Ryan VanderMeulen [:RyanVM]
	Comment 23 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/ec570b09456d

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 24 • 9 years ago

This seems to have broken a test in browser-chrome-2: 

https://treeherder.mozilla.org/logviewer.html#?job_id=7816411&repo=mozilla-inbound

I'm not seeing either bz or bholley on irc, so I'm not sure where that leaves us.

	Andrew McCreight [:mccr8]
	Comment 25 • 9 years ago

(In reply to Wes Kocher (:KWierso) from comment #24)
> This seems to have broken a test in browser-chrome-2:

	Andrew McCreight [:mccr8]
	Comment 26 • 9 years ago

INFO TEST-START | browser/components/uitour/test/browser_no_tabs.js
INFO checking window state
Entering test test_windowless_UITour
Adding UITour permission to the test page.
Console message: Security Error: Content at resource://gre-resources/hiddenWindow.html may not load or link to chrome://global/content/mozilla.xhtml.
Console message: 1426808735046	Toolkit.GMP	WARN	GMPInstallManager.parseResponseXML got node name: html, expected: updates
Console message: [JavaScript Error: "1426808735047	Toolkit.GMP	ERROR	GMPInstallManager.simpleCheckAndInstall Could not check for addons: {"target":{},"message":"got node name: html, expected: updates"}" {file: "resource://gre/modules/Log.jsm" line: 749}]
Console message: 1426808735134	Services.HealthReport.HealthReporter	WARN	Saved state file does not exist.

	Bobby Holley (:bholley)
	Comment 27 • 9 years ago

Looking at this with MattN now.

	Andrew McCreight [:mccr8]
	Comment 28 • 9 years ago

There's also a buffer overflow in that log, which is alarming, but it is pre-existing. I'll try to figure out something about that...

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 29 • 9 years ago

bc3 also seems to have gone orange with this patch: https://treeherder.mozilla.org/logviewer.html#?job_id=7815533&repo=mozilla-inbound

	Andrew McCreight [:mccr8]
	Comment 30 • 9 years ago

(In reply to Wes Kocher (:KWierso) from comment #29)
> bc3 also seems to have gone orange with this patch:
> https://treeherder.mozilla.org/logviewer.html#?job_id=7815533&repo=mozilla-
> inbound

The relevant error there is:
  Security Error: Content at resource://gre-resources/hiddenWindow.html may not load or link to chrome://global/content/mozilla.xhtml.

(I filed bug 1145443 for the buffer overflow.)

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 31 • 9 years ago

>  Security Error: Content at resource://gre-resources/hiddenWindow.html may not load or
> link to chrome://global/content/mozilla.xhtml.

Oh.  This is the "people like sticking random iframes in the hidden window" business.  :(

And of course it's a non-Mac-only problem because on Mac hiddenwindow is a chrome:// URI.

One option is to just specifically whitelist hiddenwindow.  Another is to change it to loading from a chrome:// (but not system principal) URI on non-Mac.  A third is to give it the system principal... I thought we were avoiding that on purpose.

	Bobby Holley (:bholley)
	Comment 32 • 9 years ago

Talked to Boris. We're just going to special-case the hiddenDOMWindow for now.

	Bobby Holley (:bholley)
	Comment 34 • 9 years ago

Comment on attachment 8580416 [details] [diff] [review]
followup.  Allow the hidden window to link to chrome things even though most resource:// URIs can't

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

::: caps/nsScriptSecurityManager.cpp
@@ +785,5 @@
>              }
>          }
>  
> +        // Special-case the hidden window: it's allowed to load
> +        // URI_IS_UI_RESOURCE no matter what.

Please add a bug reference to the followup to fix this terrible business.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 35 • 9 years ago

Done, and https://hg.mozilla.org/integration/mozilla-inbound/rev/8428dce9dde0

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 36 • 9 years ago

And https://hg.mozilla.org/integration/mozilla-inbound/rev/ae2217c25cee because muscle memory and I had it as nsCString when I test-compiled, apparently....

	Ryan VanderMeulen [:RyanVM]
	Comment 37 • 9 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/bd599bf81cc7
https://hg.mozilla.org/releases/mozilla-beta/rev/2e6977da201e
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/b33337093643
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/cf57dd995116
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/fae13ac7ba41
https://hg.mozilla.org/releases/mozilla-esr31/rev/a19b905f4a8a (GECKO3150esr_2015021713_RELBRANCH)
https://hg.mozilla.org/releases/mozilla-esr31/rev/9db79ef21642 (default)

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 38 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/8428dce9dde0
https://hg.mozilla.org/mozilla-central/rev/ae2217c25cee

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 39 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/ec570b09456d

	Ryan VanderMeulen [:RyanVM]
	Comment 40 • 9 years ago

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2e6977da201e
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/b33337093643
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/cf57dd995116

	Ryan VanderMeulen [:RyanVM]
	Comment 41 • 9 years ago

Per IRC discussion, backed out from the GECKO3150esr_2015021713_RELBRANCH so we can spin a 31.5.2 build in case we don't want to ship this in ESR 31.5.1. It's still on default for ESR 31.6.

https://hg.mozilla.org/releases/mozilla-esr31/rev/e647fda03631

	Ioana Chiorean
	Comment 42 • 9 years ago

On mobile - we get the same results, displays before and after the fix. I am not sure if there is something physical to observe. we did copy the files unziped and the demo on the SD card.
Is there a way to verify it for mobile?

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 43 • 9 years ago

ni bz and bholley to help Ioanna understand the test case for mobile.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 44 • 9 years ago

Does mobile ship pdf.js?

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 45 • 9 years ago

Just confirmed with nalexander that we only ship pdf.js in Fennec Nightly.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 46 • 9 years ago

Does this bug only reproduce with pdf.js? Are there other scenarios that we need to test?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 47 • 9 years ago

pdfjs was just used here as a steppingstone to chrome access.

The steppingstone part is hard to reproduce with something else.  The cross site scripting (which is covered by bug 1144988) should be possible to reproduce this with an arbitrary cross-site url, I'd think.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 48 • 9 years ago

Given that this was verified on desktop, is a platform fix, is difficult to verify on mobile, and that we want to ship today, I think we should probably accept this bug as verified. Any objections?

	Bobby Holley (:bholley)
	Comment 49 • 9 years ago

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #48)
> Given that this was verified on desktop, is a platform fix, is difficult to
> verify on mobile, and that we want to ship today, I think we should probably
> accept this bug as verified. Any objections?

Yes, I think that's fine.

	Kevin Brosnan [Ex-Mozilla]
	Comment 50 • 9 years ago

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #45)
> Just confirmed with nalexander that we only ship pdf.js in Fennec Nightly.

We don't ship pdf.js on any channel on Android. There was a period when we did but that was years ago. None of the prefs for pdf.js are present on Nightly Android. Greping the apk for pdfjs or pdf.js turns up no results. Where as greping for the strings on nightly desktop returns results.

	Bogdan Maris, Desktop QA
	Comment 51 • 9 years ago

Reproduced on Fx 37.0b4 under Win 7 x64 - with the .html file from comment 1 and common.js from .zip file, I get the following results: the iframe is empty, Total time taken is 0.381 s and a cmd window is launched.
Browser console output:

> ReferenceError: FirefoxCom is not defined l10n.js:100:4
> ReferenceError: MessageChannel is not defined svg>:1:0
> Error: Permission denied to access property "wrappedJSObject" svg>:1:0

Verified as fixed under Windows 7 x64, OS X 10.9.5 and Ubuntu 14.04 x32 :
- Total time taken is empty, no cmd window, iframe not empty
- Browser console output for Fx 37.0 build 2 (20150326190726), latest Aurora 38.0a2 (from 2015-03-29) and Nightly 39.0a1 (from 2015-03-29) e10s on/off:

> ReferenceError: FirefoxCom is not defined l10n.js:100:4
> ReferenceError: MessageChannel is not defined svg>:1:0
> "An error occurred while loading the PDF.
> PDF.js v1.1.24 (build: f6a8110)
> Message: undefined" viewer.js:6023

- Browser console output for ESR 31.6.0 build 2 (20150325203137)
 
> ReferenceError: FirefoxCom is not defined l10n.js:100
> ReferenceError: MessageChannel is not defined svg>:1
> "Error: stream must have data" pdf.worker.js:215
> "assert@resource://pdf.js/build/pdf.worker.js:232:5
> init@resource://pdf.js/build/pdf.worker.js:4615:5
> PDFDocument@resource://pdf.js/build/pdf.worker.js:4606:7
> LocalPdfManager@resource://pdf.js/build/pdf.worker.js:4201:5
> getPdfManager@resource://pdf.js/build/pdf.worker.js:36831:11
> wphSetupDoc@resource://pdf.js/build/pdf.worker.js:36997:7
> messageHandlerComObjOnMessage@resource://pdf.js/build/pdf.worker.js:1115:9
> " pdf.worker.js:217
> "Warning: Unsupported feature "unknown"" pdf.worker.js:200
> "Warning: Unsupported feature "unknown"" pdf.js:200
> "An error occurred while loading the PDF.
> PDF.js v1.0.68 (build: ead4cbf)

Is this enough to call this verified? Does the console output look to you?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 52 • 9 years ago

You should be seeing messages (perhaps in the web console, not the browser console?) about "Security Error: Content at resource://... may not load or link to chrome://..." or so.  At least after the fix.  Are you not seeing those?

I guess it's possible that with the cross-origin bits fixed (in a different bug) that testcase no longer even reaches the code that was changed in this bug...

	Bogdan Maris, Desktop QA
	Comment 53 • 9 years ago

Unfortunately, I did not see any security error via the web console nor the browser
console. The only difference between a broken build and a fixed one is what I mentioned in comment 51.

Is it a must for this error to show up or the results I got are enough?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 54 • 9 years ago

It really depends on which exact builds you're testing and what patches they have in them.  If the post-fix build has the patch for bug 1144988 in it, you won't even reach the code this bug modified using the testcase in this bug.

Here's a good way to verify this bug directly without interference from bug 1144988:

1)  Load resource://gre/modules/Services.jsm in Firefox.
2)  Open the web console (Tools > Web Developer > Web Console).
3)  Execute the following code in the console:

  var i = document.createElement("iframe"); i.src = "chrome://browser/content/browser.xul"; document.body.insertBefore(i, document.body.firstChild)

With this bug fixed, the iframe should stay blank and the browser console should show:

  Security Error: Content at resource://gre/modules/Services.jsm may not load or link to chrome://browser/content/browser.xul.

Without this bug fixed, there will be no security error like that, and the iframe will contain a (broken) version of the Firefox UI.

	Bogdan Maris, Desktop QA
	Comment 55 • 9 years ago

Thanks! 
Verified as fixed with Firefox 31.6.0 ESR build 2, Firefox 37.0 build 2, Firefox 38 beta 1 and latest Aurora 39.0a2 under Windows 7 x64, OS X 10.9.5 & Ubuntu 14.04 x32 - security error is present in Browser console with str from comment 54
No error on Firefox 37 beta 4 with the same steps.

	Petruta Horea [:phorea], Desktop QA
	Comment 56 • 9 years ago

Reproduced with the steps from comment 54 using Firefox 37 beta 6.
Verified as fixed using Firefox 38.0ESR under Win 8 32-bit, Ubuntu 12.04 32-bit and Mac OS X 10.9.5.

Marking as verified based on this. Please let me know if other verification is also needed.