1240372 - Firefox crash using malformed html tag in iframe

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Abdulrahman Alqabandi]

Attachment: q.html

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36

Steps to reproduce:

I was developing a little tool I was working on which uses data uris inside an iframe to detect potential xss vectors.

Run the tool (attached) and simply press 'go' and firefox should crash.

I am using ff v43.0.4 on windows 8.1

im attaching the full windbg logs


Actual results:

crash, will post later when I find out what happened.

NOTE: im not sure about the cause as described in the title (complete assumption), I will update it once I isolate the cause.


Expected results:

no crash

Comment 1

[Abdulrahman Alqabandi]

Attachment: Full windbg log

Comment 2

[Abdulrahman Alqabandi]

Crash report: https://crash-stats.mozilla.com/report/index/f6215e38-e379-4de1-a352-78c442160117

Comment 3

[Abdulrahman Alqabandi]

First thing I noticed is that unless your mouse is hovering ontop of the small iframe window, instead of a crash, you will receive a 'stop script' dialogue indefinitely.

So, make sure your mouse is on top of the small iframe during the initial hang (after you press GO) and the crash should occur.

Comment 4

[Abdulrahman Alqabandi]

Hrmm, it also seems like some copy pasting is required to fully reproduce the crash. (no idea why)

Here are more specific steps:

1)Open attached PoC file.
2)Replace the default value of the first input field from '<svg{q}onload={q}{b}>' to '<svg{q}onload={b}>'
3)Press 'GO' and after ~2-3 seconds press 'Stop'
4)Modify the initially modified text field and copy paste '{q}' before the '{b}' so it will look like '<svg{q}onload={q}{b}>' again.
5)Press 'GO' again, ensure mouse is hovering on the iframe (click at it as well for good measure).

Crash should occur.

Comment 5

[:Gijs (he/him)]

Can you provide a crash-stats link from about:crashes ?

Comment 6

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #5)
> Can you provide a crash-stats link from about:crashes ?

Oops, I missed comment #2 . At a glance, this looks like an editor crash, but I could be wrong.

Comment 7

[Gabor Krizsanits (INACTIVE)]

(In reply to Abdulrahman Alqabandi from comment #2)
> Crash report:
> https://crash-stats.mozilla.com/report/index/f6215e38-e379-4de1-a352-
> 78c442160117

Stack between 4 and 5 seems to be pretty random. Same for the attached stack, it's also quite broken. I would think that something bad is going on in the jit, but I'm not sure. My knowledge about jit is nearing zero :(

Comment 8

[Abdulrahman Alqabandi]

On Nightly v46.0a1 it does not seem like I can produce a crash, however, the 'unresponsive script' dialogue appears and despite choosing 'dont show me this again' and choosing to stop script, the dialogue reappears after a while over and over again.  All the while you cant exit out of nightly and only way to do so is to manually shut down the nightly process.

Comment 9

[Gabor Krizsanits (INACTIVE)]

(In reply to Abdulrahman Alqabandi from comment #8)
> On Nightly v46.0a1 it does not seem like I can produce a crash, however, the
> 'unresponsive script' dialogue appears and despite choosing 'dont show me
> this again' and choosing to stop script, the dialogue reappears after a
> while over and over again.  All the while you cant exit out of nightly and
> only way to do so is to manually shut down the nightly process.

Could you check it with e10s off? (Preferences->General->Startup->Enable multi-process nightly check-box turns it on/off)

Comment 10

[Abdulrahman Alqabandi]

Attachment: screenshot

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #9)
> Could you check it with e10s off? (Preferences->General->Startup->Enable
> multi-process nightly check-box turns it on/off)
Looks like its disabled due to something, not sure what im missing here?

Comment 11

[Abdulrahman Alqabandi]

Is it because my laptop has touchscreen?

Comment 12

[Gabor Krizsanits (INACTIVE)]

(In reply to Abdulrahman Alqabandi from comment #11)
> Is it because my laptop has touchscreen?

Alright thanks, and never mind then, I was just wondering if it's in multi-process mode or not, but then it cannot be. And yes it's most likely because of that.

Comment 13

[Abdulrahman Alqabandi]

Is this an exploitable crash?

Comment 14

[Abdulrahman Alqabandi]

Attachment: windbg logs 2

Tested the crash on FF v43.0.4 (through windbg) again and it seems like im getting a completely different crash this time.
Attaching windbg logs

Will see if I get different crash reports using the crash-reporter, will post soon.

Comment 15

[Abdulrahman Alqabandi]

Using FFv43.0.4 - I crashed firefox twice and reported the crash using the crash reporter. 

Seems like both crashes are different

https://crash-stats.mozilla.com/report/index/8037c66f-94cf-4fa3-afcb-2e5582160119

https://crash-stats.mozilla.com/report/index/3bdff7fd-c712-4d34-baf3-49a5c2160119

Would this mean that this crash is an exploitable one?

Comment 16

[Abdulrahman Alqabandi]

0:000> !exploitable -v

!exploitable 1.6.0.0
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
Exception Faulting Address: 0x8
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Write Access Violation

Faulting Instruction:5800b2c6 mov word ptr [eax+8],cx

Basic Block:
    5800b2c6 mov word ptr [eax+8],cx
       Tainted Input operands: 'cx','eax'
    5800b2ca mov esi,dword ptr [esp+18h]
    5800b2ce mov ebx,dword ptr [edi+13ch]
    5800b2d4 and esi,0ffff0005h
    5800b2da add ebx,8
    5800b2dd or esi,5
    5800b2e0 test byte ptr [esp+18h],4
    5800b2e5 jne xul!nsdocumentencoder::encodetostringwithmaxlength+0x45df82 (584691ae)

Exception Hash (Major/Minor): 0x341d4743.0xcdc8e516

 Hash Usage : Stack Trace:
Major+Minor : xul!nsDocumentEncoder::EncodeToStringWithMaxLength+0x9a
Major+Minor : xul!nsDocumentEncoder::EncodeToString+0x10
Major+Minor : xul!nsPlaintextEditor::OutputToString+0x18c
Major+Minor : xul!nsTextEditorState::GetValue+0x12c
Major+Minor : xul!mozilla::dom::HTMLInputElement::GetValueInternal+0x3f
Minor       : xul!mozilla::dom::HTMLInputElement::GetValue+0x17
Minor       : xul!mozilla::dom::HTMLInputElementBinding::get_value+0x46
Minor       : Unknown
Instruction Address: 0x000000005800b2c6
Source File: c:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\dom\base\nsdocumentencoder.cpp
Source Line: 1105

Description: Possible Stack Corruption
Short Description: PossibleStackCorruption
Exploitability Classification: UNKNOWN
Recommended Bug Title: Possible Stack Corruption starting at xul!nsDocumentEncoder::EncodeToStringWithMaxLength+0x000000000000009a (Hash=0x341d4743.0xcdc8e516)

The stack trace contains one or more locations for which no symbol or module could be found. This may be a sign of stack corruption.

Comment 17

[Abdulrahman Alqabandi]

This is a third crash that has different signature.

0:000> !exploitable -v

!exploitable 1.6.0.0
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
Exception Faulting Address: 0x8
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Write Access Violation

Faulting Instruction:57f4b2c6 mov word ptr [eax+8],cx

Basic Block:
    57f4b2c6 mov word ptr [eax+8],cx
       Tainted Input operands: 'cx','eax'
    57f4b2ca mov esi,dword ptr [esp+18h]
    57f4b2ce mov ebx,dword ptr [edi+13ch]
    57f4b2d4 and esi,0ffff0005h
    57f4b2da add ebx,8
    57f4b2dd or esi,5
    57f4b2e0 test byte ptr [esp+18h],4
    57f4b2e5 jne xul!js::contextoptions::operator=+0xeebee (583a91ae)

Exception Hash (Major/Minor): 0x836c0a71.0xee2736ad

 Hash Usage : Stack Trace:
Major+Minor : xul!JS::CallbackTracer::dispatchToOnEdge+0xbf985
Instruction Address: 0x0000000057f4b2c6

Description: User Mode Write AV near NULL
Short Description: WriteAVNearNull
Exploitability Classification: UNKNOWN
Recommended Bug Title: User Mode Write AV near NULL starting at xul!JS::CallbackTracer::dispatchToOnEdge+0x00000000000bf985 (Hash=0x836c0a71.0xee2736ad)

User mode write access violations that are near NULL are unknown.

Comment 18

[Andrew McCreight [:mccr8]]

The crashes in nsDocumentEncoder::EncodeToStringWithMaxLength() look like a failure to do a null check on the result of calling nsStringBuffer::Alloc() that failed due to being low on memory. The crash in JS::CallbackTracer::dispatchToOnEdge() may be some other OOM crash. It is hard to say without more of the stack. So this doesn't look particularly exploitable based on the information from the crash stacks.

Comment 19

[Andrew McCreight [:mccr8]]

Ehsan, does this just look like a safe OOM crash to you?

Comment 20

[(no longer active)]

Yeah, this is totally an OOM crash.  I think we should open up the bug.

I'll write a patch to add a null check.

Comment 21

[(no longer active)]

Attachment: Don't OOM crash in nsDocumentEncoder::EncodeToStringWithMaxLength() when the string buffer allocation fails

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8709679 [details] [diff] [review]
Don't OOM crash in nsDocumentEncoder::EncodeToStringWithMaxLength() when the string buffer allocation fails

r=me

Comment 23

[Pulsebot]

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

Comment 24

[Carsten Book [:Tomcat]]

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