See bug 355548 for the discussion on related issue. In this particular case, nsTextControlFrame::CreateAnonymousContent does attribute manipulation on the content <div> and this fires DOMAttrModified event, which in this context is unsafe.
Created attachment 266754 [details] [diff] [review] WIP Will do some tests, and possibly add a method to nsGenericHTMLFormElement to test whether mutation event is coming from native anon.
Status: NEW → ASSIGNED
Component: Layout → DOM: Events
Created attachment 266793 [details] [diff] [review] proposed patch Handling mutation events the same way in input and textarea. <select> has also some native anon content, but couldn't get it to crash the same way as <textarea>. (I did find one crash, but that is null pointer thingie). On trunk mutation events from native anon are always prevented, but that relies on the new event dispatching code.
I'm working on a related testcase to crash generic scrollable frame code (the same stuff in nsGfxScrollFrameInner::CreateAnonymousContent()). The whole thing of branches firing mutation whenever a frame changes something in content is vulnerable IMO.
(In reply to comment #4) > The whole thing of branches firing mutation whenever a frame changes something > in content is vulnerable IMO. > Yes, it is, though in trunk there shouldn't be any problems if content is native anonymous. And note, nsGfxScrollFrame(Inner) has changed quite a bit since 1.8. If you find a new crash, IsEventHandlingDisabled could be moved up to nsGenericElement.
Could not get it to crash in this particular case, but definitely was able to trash the UI thread with stuff, see bug 382681.
Comment on attachment 266793 [details] [diff] [review] proposed patch I'd take this to 1.8 and if someone can write a testcase where mutation events coming from native anonymous are causing crashes, ::IsEventHandlingDisabled() could be pushed up to nsGenericElement, (or a new patch with similar functionality could be written).
Why not approval126.96.36.199 as well though? I'll try to generate another testcase...
Will there be 188.8.131.52? I thought 184.108.40.206 was the last 1.8.0.x one.
Indeed. Why do we get those guys in bugzilla then?
There will be a 220.127.116.11 for Thunderbird, but [probably] not for Firefox. The flags exist for those bugs, aiui.
Ok, then the flag should be probably up, and also for those guys who might still use 1.8.0 layout in their code..
@Smaug: I finally was able to crash scrollable frame code, see attachment 267625 [details]. Is that enough to warrant promotion of attachment 266793 [details] [diff] [review] to nsGenericElement?
Because of XUL's strange way to flag native anonymous content, that may not work after all. I'll do some tests and write a bit different kind of patch if needed.
So the patch in Bug 382681 fixes this too.
Fixed by the patch in bug 382681.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed18.104.22.168, fixed22.214.171.124
Resolution: --- → FIXED
In FF126.96.36.199 the crash I get is a null deref. This testcase doesn't lead to an exploitable situation but that doesn't mean these unsafe events can't be abused in other ways.
Whiteboard: [sg:low? null deref?]
I can verify that we don't crash using Thunderbird version 188.8.131.52 (20070809) (Mac OS X) using the testcase in comment 0; replacing fixed184.108.40.206 with verified220.127.116.11.
Keywords: fixed18.104.22.168 → verified22.214.171.124
Whiteboard: [sg:low? null deref?] → [sg:low? null deref?] keep private until 355548 is fixed
crash test landed http://hg.mozilla.org/mozilla-central/rev/ae37a2531c4b
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.