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.
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.
In FF18.104.22.168 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.
I can verify that we don't crash using Thunderbird version 22.214.171.124 (20070809) (Mac OS X) using the testcase in comment 0; replacing fixed126.96.36.199 with verified188.8.131.52.
crash test landed http://hg.mozilla.org/mozilla-central/rev/ae37a2531c4b