1249521 - Abusing DataTransfer.setData can crash Firefox

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

Description

[Rafael Gieschke]

+++ This bug was initially created as a clone of Bug #1226977 +++

These are crashes occurring when using very long strings for format and data in DataTransfer.setData(format, data) found during investigating bug 1226977.

The Windows bug reports are from a rather memory-limited VM.

1. Visit <...>.
2. Drag the Firefox image.
3. Firefox will crash.


https://ebenda.org/2015/drag-drop/flood2.html (Windows-only)

Firefox 44: bp-7bff1377-83d4-4944-88fb-9e9c52160219
Firefox Nightly (with Electrolysis) (only crashes tab): bp-175519e6-3b8f-4044-875d-f98af2160219


https://ebenda.org/2015/drag-drop/flood3.html (Linux-only)

Firefox 44: bp-72d61740-bae4-475c-be1e-482b22160219
Firefox Nightly: bp-cfc68cbb-717c-44d9-a780-931462160219


https://ebenda.org/2015/drag-drop/flood4.html (Windows-only)

Firefox 44: bp-983932bb-afa2-4553-b282-83e0d2160219
Firefox Nightly (with Electrolysis) (crashes browser): bp-048596b4-db7b-4bd9-aca9-4ee822160219

Comment 1

[Benjamin Smedberg]

Not a security issue, these are "safe" crashes.

The stack that is most common here is:

3 	xul.dll 	ToNewUnicode(nsAString_internal const&) 	xpcom/string/nsReadableUtils.cpp
4 	xul.dll 	nsDiscriminatedUnion::ConvertToWStringWithSize(unsigned int*, wchar_t**) 	xpcom/ds/nsVariant.cpp
5 	xul.dll 	mozilla::dom::DataTransfer::ConvertFromVariant(nsIVariant*, nsISupports**, unsigned int*) 	dom/events/DataTransfer.cpp
6 	xul.dll 	mozilla::dom::DataTransfer::GetTransferable(unsigned int, nsILoadContext*) 	dom/events/DataTransfer.cpp

It's not hard to make ToNewUnicode fallible (there may already be a fallible version). But I'm less sure about the nsDiscriminatedUnion/nsVariant error propagation back to DataTransfer::ConvertFromVariant. Variants suck bigtime and most code doesn't expect the basic methods to fail.

Comment 2

[Rafael Gieschke]

Thanks for looking at them. Yeah, they looked like Firefox crashing intentionally because of being OOM, just wanted to make sure I am interpreting this correctly :-).

They do contain URLs leading to unsafe content, though. I checked the log files that this was not accessed in the last hour and will move the unsafe content to other locations.

Comment 3

[Rafael Gieschke]

Oh, sorry, changing the group back was not intentional :-( (and I think I cannot undo this but you can open the bug up again, sorry).

Comment 4

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.