622501 - HTMLparser DOCTYPE Denial of service.

Status: NEW

(Core :: DOM: HTML Parser, defect, P5)

Description

[Alexandra (retired)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.2.13) Gecko/20101203
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.2.13) Gecko/20101203

In http://mxr.mozilla.org/mozilla1.9.2/source/parser/htmlparser/src/nsParser.cpp#1096

There is a block of code that checks the DOCTYPE of a document. Starting on line 1094 we noticed that if we insert a succession of '<' & '!' chars with whitespace but without the DOCTYPE or closing bracket '>', the loop will continue until it finds the DOCTYPE. With this is mind, we can create a denial of service with solely ASCII characters. See attached test case. When you add a closing bracket '>' at the end of the file, the denial of service will not occur. In order to keep the test case in a reasonable size, we added a meta refresh to emulate a larger file (5MB+) the meta tag does affect the vulnerability.

1094   PRInt32 theIndex = 0;
1095   do {
1096     theIndex = aBuffer.FindChar('<', theIndex);
1097     if (theIndex == kNotFound) break;
1098     PRUnichar nextChar = aBuffer.CharAt(theIndex+1);
1099     if (nextChar == PRUnichar('!')) {
1100       PRInt32 tmpIndex = theIndex + 2;
1101       if (kNotFound !=
1102           (theIndex=aBuffer.Find("DOCTYPE", PR_TRUE, tmpIndex, 0))) {
1103         haveDoctype = PR_TRUE;
1104         theIndex += 7; // skip "DOCTYPE"
1105         break;
1106       }
1107       theIndex = ParsePS(aBuffer, tmpIndex);
1108       theIndex = aBuffer.FindChar('>', theIndex);
1109     } else if (nextChar == PRUnichar('?')) {
1110       theIndex = aBuffer.FindChar('>', theIndex);
1111     } else {
1112       break;
1113     }
1114   } while (theIndex != kNotFound);

Reproducible: Always

Steps to Reproduce:
1. run attached test case
Actual Results:  
Approx. 98% spike in CPU for minutes. (mileage may vary, due to CPU)

Expected Results:  
Restrict loop on parsing the doctype.

Comment 1

[Alexandra (retired)]

Attachment: Testcase.

Comment 2

[Alexandra (retired)]

Attachment: Source.

Comment 3

[Ed Morley [:emorley]]

Confirmed with 3.6.13, Win7.

Does not occur with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre ID:20110103030359, other than for ~10 seconds after opening view source, but presumably this is expected behaviour since it's trying to do the syntax highlighting.

Shouldn't this be marked with the security hidden flag?

Comment 4

[Alexandra (retired)]

Hi Ed, feel free to mark it. I'm not sure if it's a huge risk so far, or that it could unearth a larger issue. Further down the code more checking is being performed, like the presence of one or more DTD SYSTEMS. 

Clock cycles affect the duration of the denial of service. I tested on a x86 Intel Pentium(R) 4 CPU 2.80GHz, 2.79 GHz, 3.00GB of RAM. The more chars the longer it takes, as expected with in the loop, therefore it might require a rather large file for fast CPU's.

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to comment #3)
> Does not occur with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre)
> Gecko/20110103 Firefox/4.0b9pre ID:20110103030359, other than for ~10 seconds
> after opening view source, but presumably this is expected behaviour since it's
> trying to do the syntax highlighting.

View Source is still using the old parser in Firefox 4.0. (Replacing View Source with a new implementation is scheduled for post-4.0.)

Comment 6

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.