Open Bug 1397642 Opened 3 years ago Updated 3 years ago
Memory corruption issue - Access violation reading address
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".
Looks like a nullptr deref in mozilla::IMEStateManager::SetIMEState. CCing Mayasuki, in the hope that he can help clarify further and forward as necessary.
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.
Component: Untriaged → Internationalization
Product: Firefox → Core
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 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.
(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.
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.