1397642 - Memory corruption issue - Access violation reading address

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P2)

Description

[Stefan Sabin Nicula]

Attachment: POC.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

Following the proof of concept attached in the "POC.zip" archive, the next steps can be taken in order to reproduce the vulnerability:

1.Open the TEST5.htm file
2.Click on the "CLICK ME" button ( a pop-up will appear with an explicit text )
3.Enter letters or symbols in the input located inside the pop-up ( please notice that inserting numbers will not help in reproducing the vulnerability)
4.Press "ENTER"  key (very important step, clicking outside the pop-up will not help)
5.Click anywhere inside Mozilla browser (preferably inside the body of the HTML page)

We can notice that after the "click" event, the crash occurs.


Actual results:

After following the given steps, the Mozilla Firefox browser crashes. The probability of crashing is 100% of the cases, the Proof of Concept was tested multiple times.

A crash occurs with the message "EXCEPTION_ACCESS_VIOLATION_READ". I will also attach a crash report ("Crash_report.txt") and a screenshot from Immunity Debugger. 

I used Immunity Debugger and attached the firefox.exe process in order to debug the scenario. After following the reproduction steps, the process halts and reads "Access violation when reading 00000010".


Expected results:

The webpage should pop-up an explicit message saying "Please enter a number".

Comment 1

[Stefan Sabin Nicula]

Attachment: Immunity Debugger print screen

Comment 2

[Stefan Sabin Nicula]

Attachment: Crash_report.txt

Comment 3

[Frederik Braun [:freddy]]

Attachment: address sanitizer output for POC

Comment 4

[Frederik Braun [:freddy]]

Looks like a nullptr deref in mozilla::IMEStateManager::SetIMEState.
CCing Mayasuki, in the hope that he can help clarify further and forward as necessary.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

According the line number, inputContent is nullptr here?
https://searchfox.org/mozilla-central/rev/67f38de2443e6b613d874fcf4d2cd1f2fc3d5e97/dom/events/IMEStateManager.cpp#1255,1259-1260

However, I don't know how nsIContent::FindFirstNonChromeOnlyAccessContent() returns nullptr.

Comment 6

[Daniel Veditz [:dveditz]]

null deref doesn't look like a security issue. Unhiding.

Comment 7

[Stefan Sabin Nicula]

Well, there is a CWE for this. Just saying.
https://cwe.mitre.org/data/definitions/476.html

Indeed, the chances of exploiting this are somewhat low taking in consideration the level of obsfucation of the js code. A more in-depth research is needed from my behalf.
However, for now I think it still has an implication regarding the business impact, I find it somewhat similar with the pop-under scheme.

Anyway, thank you for the prompt replies and clarifications.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Stefan Sabin Nicula from comment #7)
> >null deref doesn't look like a security issue. Unhiding.
>
> Well, there is a CWE for this. Just saying.
> https://cwe.mitre.org/data/definitions/476.html

Excuse my insider brevity. A guaranteed null-deref isn't the kind of bug where the security risks to users is so high that we need to keep the bug hidden to protect them, because hidden bugs come at the cost of openness and a better chance to get stability issues fixed by a broader group of folks.

I'm also sorry to say that Denial of Service bugs are excluded from our bug bounty program.