239840 - (CVE-2006-2723) hang when many nested <marquee> tags are used. exponential time increase

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[nomel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

A clickable example with a time vs #of <dl> tags graph is located at
http://broken.pc.cz/index.html. The actual html that causes the hang is at
http://broken.pc.cz/test.htm (carefull!). Hang seems to be extremely slow
rendering. This DOES effects Mozilla, Firefox, and Safari. DOES NOT effect Opera
and IE. All others are untested. 

Reproducible: Always
Steps to Reproduce:
1.Open html with hang code.
Actual Results:  
Hang. It does resume after certain amount of time. This time can be extended
into years though.

Expected Results:  
Not rendered the page correctly to keep from having problems, or rendered
marquee without indentation from <dl>, or displayed a warning.

All times on graph at http://broken.pc.cz/index.html were for a 1Ghz PIII.

Comment 1

[Greg Campbell]

confirmed
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040402
Firefox/0.8.0+

Comment 2

[Martijn Wargers (dead)]

Attachment: Attached testcase

Same testcase as mentioned before.

It hangs on my computer too, but when I have javascript turned off, it doesn't
hang.

Comment 3

[Martijn Wargers (dead)]

I see this also in Mozilla1.7RC2

Comment 4

[basic]

with a recent moz cvs trunk build all I see Javascript errors about too much
recursion, no "hang". fixed?

Comment 5

[basic]

ok spoke too soon, will investigate

Comment 6

[basic]

a slightly different testcase from bug 265027
https://bugzilla.mozilla.org/attachment.cgi?id=162508&action=view

no <dl>s just <marquee>s with huge height attributes.

Comment 7

[Bernd]

I split the marquee hang from comment 6 into bug 288931 as it is very different

Comment 8

[Martijn Wargers (dead)]

Ok, with current trunk build it doesn't hang anymore, it's just slow.
With Mozilla1.7, I hang, so something has definetely improved since then.

Comment 9

[Jared]

This is still an issue, confirmed with Firefox 1.5.0.3.  Also, this issue has been posted to BugTraq (which is where I learned of it), so visibility is likely to soon rise.

A fix would really be a good thing.

Comment 10

[Steve Russell (RaiseMachine)]

Confirmed with Bon Echo using BugTraq example.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060530 BonEcho/2.0a3

Comment 11

[Steve Russell (RaiseMachine)]

Attachment: BugTraq Testcase

Should have attached this to my last post.

Comment 12

[Patrick]

Confirmed using testcase on WinXP SP1 w/ FF 1.5.0.3. I saw this on BugTraq, also. I'm surprised this hasn't been fixed yet...

Comment 13

[Daniel Veditz [:dveditz]]

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

Comment 14

[brad.berkemier]

Using BugTraq test case.

Confirmed in:

Firefox Current Release -
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Mozilla Latest Nightly - 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702

WFM in:

Firefox Latest Trunk Nightly - 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1

Seems to be fixed in the trunk.

Comment 15

[Patrick]

Confirmed for me in 1.5.0.4, WinXP/SP1.

Comment 16

[Robert Ames]

fixing up title for searching (added nested, de-emphasizing DL tags), indicating relation to Bug #339954 .

Original title: "hang when many <dl> and <marquee> tags are used. exponential time increase depending on number of <dl> tags.."

New title: "hang when many nested <marquee> tags are used. exponential time increase"

Comment 17

[Robert Ames]

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

Comment 18

[Jesse Ruderman]

Dup of bug 277208?  (Which is fixed on trunk, btw)

Comment 19

[David Farning]

Can confirm that the first Attached testcase still hangs 2.0.

David

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Was there anything in this bug to make you think it was fixed for 2.0?
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 21

[Ryan VanderMeulen [:RyanVM]]

(In reply to comment #18)
> Dup of bug 277208?  (Which is fixed on trunk, btw)
> 

Definitely not. Testcase still kills the trunk.

Comment 22

[Martijn Wargers (dead)]

(In reply to comment #21)
> Definitely not. Testcase still kills the trunk.

Oops, yes, it is now crashing current trunk builds, this is something new, I filed bug 363722 for it. This bug is for the hanging issue (which may return after bug 363722 gets fixed).

Comment 23

[Kees Cook]

This seems to have been assigned a CVE, though not specific to firefox: CVE-2006-6954

Comment 24

[Fernando Hartmann]

There are another example (exploit) on the following link 

http://milw0rm.com/exploits/3606

The marquee tags are placed before the head tag.

Comment 25

[Daniel Veditz [:dveditz]]

... and earlier http://milw0rm.com/exploits/1867

CVE-2006-2723 is more appropriate, -6954 seems to be the Flock variant of the same thing.

Comment 26

[Valerio Santinelli]

It still happens quite frequently for me when opening certain myspace.com profiles. (with v2.0.0.11)

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Thanks for the report, but please consider the Bugzilla etiquette guidelines before posting more "me too" comments in the future so that developers can more easily see the relevant information in a bug and so that people CCed to a bug (like myself) aren't needlessly spammed.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 30

[Mike Kaply [:mkaply]]

This doesn't happen with our new Marquee implementation.

Comment 31

[Frederik Braun [:freddy]]

This was fixed via bug 1425874.