Firefox crash using malformed html tag in iframe

RESOLVED FIXED in Firefox 46

Status

()

Core
DOM
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Abdulrahman Alqabandi, Assigned: Away for a while)

Tracking

({crash, csectype-oom})

43 Branch
mozilla46
crash, csectype-oom
Points:
---

Firefox Tracking Flags

(firefox46 fixed)

Details

(Whiteboard: [sg:dos])

Attachments

(5 attachments)

(Reporter)

Description

2 years ago
Created attachment 8708789 [details]
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
(Reporter)

Comment 1

2 years ago
Created attachment 8708790 [details]
Full windbg log
(Reporter)

Comment 2

2 years ago
Crash report: https://crash-stats.mozilla.com/report/index/f6215e38-e379-4de1-a352-78c442160117
(Reporter)

Comment 3

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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 hidden (obsolete)

Comment 6

2 years ago
(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.
Group: firefox-core-security → core-security
Component: Untriaged → Editor
Flags: needinfo?(qab)
Product: Firefox → Core
(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 :(
(Reporter)

Comment 8

2 years ago
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.
(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)
(Reporter)

Comment 10

2 years ago
Created attachment 8709027 [details]
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?
Flags: needinfo?(gkrizsanits)
(Reporter)

Comment 11

2 years ago
Is it because my laptop has touchscreen?
(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.
Flags: needinfo?(gkrizsanits)
(Reporter)

Comment 13

2 years ago
Is this an exploitable crash?
(Reporter)

Comment 14

2 years ago
Created attachment 8709268 [details]
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.
(Reporter)

Comment 15

2 years ago
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?
Flags: needinfo?(gkrizsanits)
(Reporter)

Comment 16

2 years ago
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.
(Reporter)

Comment 17

2 years ago
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ehsan, does this just look like a safe OOM crash to you?
Flags: needinfo?(gkrizsanits) → needinfo?(ehsan)
(Assignee)

Comment 20

2 years ago
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.
Flags: needinfo?(ehsan)
(Assignee)

Updated

2 years ago
Assignee: nobody → ehsan
Component: Editor → DOM
Group: core-security
Keywords: crash
(Assignee)

Comment 21

2 years ago
Created attachment 8709679 [details] [diff] [review]
Don't OOM crash in nsDocumentEncoder::EncodeToStringWithMaxLength() when the string buffer allocation fails
Attachment #8709679 - Flags: review?(bzbarsky)
Comment on attachment 8709679 [details] [diff] [review]
Don't OOM crash in nsDocumentEncoder::EncodeToStringWithMaxLength() when the string buffer allocation fails

r=me
Attachment #8709679 - Flags: review?(bzbarsky) → review+

Comment 23

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

Comment 24

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f13aab93f3a3
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Keywords: csectype-oom
Whiteboard: [sg:dos]
You need to log in before you can comment on or make changes to this bug.