Closed
Bug 382568
Opened 18 years ago
Closed 18 years ago
Unsafe DOM mutation events in <textarea>
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: vladimir.sukhoy, Assigned: smaug)
References
Details
(4 keywords, Whiteboard: [sg:low? null deref?] keep private until 355548 is fixed)
Attachments
(2 files, 1 obsolete file)
1.23 KB,
application/xhtml+xml
|
Details | |
6.64 KB,
patch
|
sicking
:
review+
sicking
:
superreview+
|
Details | Diff | Splinter Review |
DOMAttrModified events are fired from the presentation code which triggers JavaScript code within unsafe context.
Reporter | ||
Comment 1•18 years ago
|
||
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.
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → Olli.Pettay
Assignee | ||
Comment 2•18 years ago
|
||
Will do some tests, and possibly add a method to nsGenericHTMLFormElement to
test whether mutation event is coming from native anon.
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Component: Layout → DOM: Events
Assignee | ||
Updated•18 years ago
|
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Assignee | ||
Comment 3•18 years ago
|
||
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.
Attachment #266754 -
Attachment is obsolete: true
Attachment #266793 -
Flags: superreview?(jonas)
Attachment #266793 -
Flags: review?(jonas)
Reporter | ||
Comment 4•18 years ago
|
||
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.
Assignee | ||
Comment 5•18 years ago
|
||
(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.
Reporter | ||
Comment 6•18 years ago
|
||
Could not get it to crash in this particular case, but definitely was able to trash the UI thread with stuff, see bug 382681.
Attachment #266793 -
Flags: superreview?(jonas)
Attachment #266793 -
Flags: superreview+
Attachment #266793 -
Flags: review?(jonas)
Attachment #266793 -
Flags: review+
Assignee | ||
Comment 7•18 years ago
|
||
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).
Attachment #266793 -
Flags: approval1.8.1.5?
Reporter | ||
Comment 8•18 years ago
|
||
Why not approval1.8.0.13 as well though?
I'll try to generate another testcase...
Assignee | ||
Comment 9•18 years ago
|
||
Will there be 1.8.0.13? I thought 1.8.0.12 was the last 1.8.0.x one.
Reporter | ||
Comment 10•18 years ago
|
||
Indeed. Why do we get those guys in bugzilla then?
Comment 11•18 years ago
|
||
There will be a 1.8.0.13 for Thunderbird, but [probably] not for Firefox. The flags exist for those bugs, aiui.
Reporter | ||
Comment 12•18 years ago
|
||
Ok, then the flag should be probably up, and also for those guys who might still use 1.8.0 layout in their code..
Reporter | ||
Comment 13•18 years ago
|
||
@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?
Assignee | ||
Comment 14•18 years ago
|
||
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.
Assignee | ||
Updated•18 years ago
|
Attachment #266793 -
Flags: approval1.8.1.5?
Updated•18 years ago
|
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Assignee | ||
Comment 15•18 years ago
|
||
So the patch in Bug 382681 fixes this too.
Assignee | ||
Comment 16•18 years ago
|
||
Fixed by the patch in bug 382681.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.0.13,
fixed1.8.0.5
Resolution: --- → FIXED
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.0.5 → fixed1.8.1.5
Comment 17•18 years ago
|
||
In FF2.0.0.4 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 1.5.0.13 (20070809) (Mac OS X) using the testcase in comment 0; replacing fixed1.5.0.13 with verified1.5.0.13.
Keywords: fixed1.8.0.13 → verified1.8.0.13
Updated•17 years ago
|
Flags: in-testsuite?
Whiteboard: [sg:low? null deref?] → [sg:low? null deref?] keep private until 355548 is fixed
Updated•16 years ago
|
Group: core-security
Comment 19•16 years ago
|
||
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.
Description
•