275654 - Stack Overflow in textarea (crash dragging?) [@ nsTextFrame::GetChildFrameContainingOffset]

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Mr Patrin Jeremy]

Stack Overflow
 
 Versions   : Firefox 1.0 , Thunderbird 0.9 tested
 Description: A stack buffer overrun in Html AeraText routines could be
              exploited to run arbitrary code supplied by the attacker.

<------------------------------------------------------------------------>
 Example:
     
<td bgcolor="#08ff7c"><textarea name="input" rows="10" cols="10"           
wrap="virtual">AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA(.....)</textarea></td> 

<--------------------------------------------------------------------------->
1. Load the web page
2. Move the mouse in aeratext........crash 
    if firefox doesn't crash, right click aeratext......crash 

    M.Patrin

Comment 1

[timeless]

please attach a real testcase.
does this happen with trunk builds of mozilla/firefox?
please install talkback into your firefox 1.0 (select custom install and check talkback) and report the 
incident id when you crash.

Comment 2

[Daniel Veditz [:dveditz]]

I can't reproduce with this testcase on Firefox 1.0, even when padding the
ellipses out to almost 5 million characters and sticking the snippet in a
minimal containing form and table.

Re-open if more details are forthcoming.

Comment 3

[Mr Patrin Jeremy]

Attachment: Test

Load test.html, move cursor in txt aera and right click

Comment 4

[Daniel Veditz [:dveditz]]

I can get the attached testcase to crash, but not mine. The only difference
(now) is that mine splits the textarea contents on 60K 80-char lines, while the
attached has one long 1.4million char line. But in both cases the text area
wraps on the spaces every ninth character.

The instructions did not produce a crash for me, ever. I could move the cursor
(text cursor or mouse? I tried both) and right and left click to my hearts
content. What did cause an immediate boom every time was doing a mousedown-drag
somewhere outside the textarea.

Talkback's stack was a long string of nothing but
nsTextFrame::GetChildFrameContainingOffset

I don't see the textarea contents anywhere in the raw talkback data, I'm pretty
confident this isn't exploitable.

Comment 5

[Daniel Veditz [:dveditz]]

same symptoms with Mozilla on the trunk.

Comment 6

[Daniel Veditz [:dveditz]]

Attachment: similar HTML that does NOT crash (.zip)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Mr Patrin Jeremy, I can't seem to extract the file you attached ("test.html -
file header broken" is what unrar says).  Could you possibly attach a zip file
showing the problem?

Comment 8

[Charles Toth]

Attachment: This crashes, 1 less group of 'A's doesn't

The following:

	I downloaded the test.rar file, unpacked it and launched it in Mozilla
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040616 W98SE with
latest service pack, 1.7 ghz Athlon on Biostar MB 386 MB ram.]


As unpacked, it crashed. I noticed that the groups of 'A's were not uniform and
fixed that. I removed HEAD, TD BGCOLOR, WRAP tags and properties. 

I removed groups of 'A's and found:

With COLS varying from 9 to 16, placing one group of 'A's on each line, we
crash at 21518 groups, but not at 21517.

With COLS varying from 17 to 25, with two groups of 'A's on each line, we have
crashes at 43035 groups, but not at 43034 groups. Check the math -- we're
crashing when in excess of 21517 lines of text in the TEXTAREA.

With COLS set at 26, we have three groups of 'A's on each line. The crash is at
64552 groups, but not 64551 groups.  The crash happens when in excess of 21517
lines of text in the TEXTAREA.

By changing the groups of 'A's to 10 and varying the COLS parameter, I was able
to duplicate the crashes after 21517 lines in the TEXTAREA.


Charles Toth
Keyser WV

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmmm...  With that last file, and a trunk build, no crash over here...

Comment 10

[Daniel Veditz [:dveditz]]

On 1.0 and the latest from the aviary branch I crash with a stack overflow as
described in comment 4. Is there a nsTextFrame::GetChildFrameContainingOffset
recursion for each line of text?

The trunk and branch versions of this routine are indentical except for some
trivial-looking deCOMtamination changes. But of course the data structures
operated on could have changed significantly elsewhere.

Comment 11

[timeless]

*** Bug 296592 has been marked as a duplicate of this bug. ***

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It also crashes my Firefox and SeaMonkey CVS-builds under Linux. While I'm using
debug builds I got no information about the crash. Anyone who can offer a stack
trace?

Comment 13

[timeless]

*** Bug 340717 has been marked as a duplicate of this bug. ***

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I can get Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060826 BonEcho/2.0b2 to crash. But although after enabling talkback the agent is never shown. Any idea how to obtain the incidient id?

Comment 17

[Boris Zbarsky [:bzbarsky]]

So yeah.  On branch, nsTextFrame::GetChildFrameContainingOffset() recurses into the next-in-flow, which means the recursion depth is the number of lines.

With the new textframe, there's just some while loops, so it's iterative, not recursive.

So on trunk this is fixed by the new textframe.  I suppose we could fix it on branch if really needed, but this isn't exploitable, so...