1144063 - crashfirefox.com makes the browser very slow or makes it crash

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

So this has been reported from a French website [0] which is pretty popular. Basically, there is this website http://crashfirefox.com, which redirects you to the following encoded URL:

    data:text/html,<script>location+=location+'A'.repeat(100000000);</script>

And that makes Firefox very slow, if not crashy. For instance, I could have a crash with e10s:

https://crash-stats.mozilla.com/report/index/6ff721d5-8bcd-4e72-b25e-e085c2150317

Note that if you have this piece of code in a <script> balise of a page (and not in the data URL), the browser doesn't crash, instead it will show this in the console:

    NS_ERROR_MALFORMED_URI: 

I don't really know which component is in fault here, but I suspect window.location somehow, or just the data URI component which should also show the NS_ERROR. Trying Core::DOM... 

[0] http://korben.info/planter-firefox-en-1-click.html

Comment 1

[Boris Zbarsky [:bzbarsky]]

Presumably the issue is just that it's a huge data: URI and we OOM on it, no?

The e10s crash linked is in e10s specific code that decides it wants to kill off the process for reasons that are not clear to me.

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

Dragana, I've seen this crash / hang with the latest nightly (I've just restarted it to ensure it's the latest), which should contain the fix in bug 1135354 (landed 03/11). But the crash still happens!

See an example of crash in latest nightly:
https://crash-stats.mozilla.com/report/index/881ce179-8ca2-42dc-a21c-aa8e52150317

Comment 4

[Dragana Damjanovic [:dragana]]

Valentin, May I ask you to take a look at this, you were fixing url stuff. :) Thanks.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Actually, bug 1135354 does not fix this.
The URI here, data:text/html,<script>location+=location+'A'.repeat(100000000);</script> is under 100 chars long, so the there's no early return for this one.

From what I can tell, the problem here is that we're trying to allocate a huge string, even before we build a URI. Boris, is there a way we can set a max limit on a string? And is that something we should do?

const&, nsID const*, nsresult*) () from /home/icecold/.apps/firefox/libxul.so
#13 0x00007fc04b3ffa96 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () from /home/icecold/.apps/firefox/libxul.so
#14 0x00007fc04b402276 in XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*) () from /home/icecold/.apps/firefox/libxul.so
#15 0x00007fc04b5b2f1d in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#16 0x00007fc04b5b3994 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#17 0x00007fc04b5b3bb4 in js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#18 0x00007fc04b5c7506 in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) ()
   from /home/icecold/.apps/firefox/libxul.so
#19 0x00007fc04b55401e in js::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#20 0x00007fc04b5a54aa in Interpret(JSContext*, js::RunState&) () from /home/icecold/.apps/firefox/libxul.so
#21 0x00007fc04b5b2a71 in js::RunScript(JSContext*, js::RunState&) () from /home/icecold/.apps/firefox/libxul.so
#22 0x00007fc04b5b3000 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#23 0x00007fc04b66a41e in js::fun_apply(JSContext*, unsigned int, JS::Value*) () from /home/icecold/.apps/firefox/libxul.so
#24 0x00007fc04b5b2f1d in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#25 0x00007fc04b5b3994 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#26 0x00007fc04b61ffec in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) ()
   from /home/icecold/.apps/firefox/libxul.so

Comment 6

[Boris Zbarsky [:bzbarsky]]

> The URI here, data:text/html,<script>location+=location+'A'.repeat(100000000);</script>
> is under 100 chars long

Yes, but it sets location to a URL that's 1e8 chars long.

> the problem here is that we're trying to allocate a huge string, even before we build a
> URI

That shouldn't be a problem per se, as long as the relevant consumers use the fallible string methods and throw as needed on failure.

> And is that something we should do?

Imo, no.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Right, the problem here isn't the actual strings, but the fact that it goes into a loop of appending to the URI and executing the script.
This URI does the same thing basically, only a bit slower:
data:text/html,<script>location+=location+'A'</script>

I'll try to add a size limit to nsLocation as well.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Adding a random size limit seems pretty odd to me.  We should be handling the OOM as needed, no?

Comment 9

[Nick B.]

If you visit the page in Chrome the tab crashes after a short while whith "Either Chrome ran out of memory or the process for the webpage was terminated for some other reason". So it seems Chrome is handling the OOM. Seems like a better way than to add a size limit.

Comment 10

[alex_mayorga]

This ended up crashing the tab process with e10s on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150415030206 CSet: a6f7a33731bc , but the signature is a bit different.

Report ID 	Date Submitted
bp-42319cff-f90e-4188-aa4f-8e6e02150415
	15/04/2015	12:46 p.m.

Comment 11

[alex_mayorga]

Tried again and got yet another signature.

Report ID 	Date Submitted
bp-3405d66f-e0d9-46e5-9892-0cbf22150419
	19/04/2015	12:23 p.m.

Shall I file separate bugs from these crashes?

Does the awesome bar have to allow <script>?

Comment 12

[Boris Zbarsky [:bzbarsky]]

I don't see what this has to do with the awesomebar per se.

Comment 13

[Karl Dubost💡 :karlcow]

Reported on Webcompat.com today
https://webcompat.com/issues/1978

Comment 15

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 16

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 17

[Valentin Gosu [:valentin] (he/him)]

This bug doesn't crash Firefox anymore due to "Navigation to toplevel data: URI not allowed"

Comment 18

[u450280]

https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-59/