265619 - Rendering large binary file as HTML makes Firefox stop responding or crash

Status: RESOLVED DUPLICATE of bug 112738

(SeaMonkey :: General, defect)

Description

[Peter Kruse]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Mozilla Firefox doesn’t validate content of HTML-files before viewing. This
could lead to memory exchaustion and DoS from remote hostile webpages. 

Mozilla doesn’t inspect content in .html filetypes allowing several ways to
exploit a DoS condition caused by memory consumption. The problem is really
basic. Internet Explorer correctly verifies the content of filtypes before
viewing in the browser. This is, by design, not the case with Mozilla based
browsers, which would allow remote websites to embed large binary files spoofed
as ordinary html files. Since Mozilla doesn’t sufficiently check the content of
the file the binary is displayed within the browser and associated memoryspace
causing Mozilla to crash if the file is large. 

You can choose any file from your harddisk larger than 4MB, rename it as a html
file, upload it to a remote website, or simply open it from your harddisk. The
result is the same: Mozilla will stop responding, showing a lot of binary
garbage, before the user is forced to either end the application or reboot the
system. In several test scenarios the system used up all virtual memory causing
the system to become unstable.

To avoid the user from being suspicious, when garbage is showed in the browser,
you can fill in empty data in the header of the binary, video stream or
whatever. This way the browser will show a blank page until it crashes and the
system becomes unstable. This trick could be planted on a website with actual
content. When viewed, the browser will load the binary in the background,
without the users knowledge. This can be accomplished with frames or a specially
formatted website. Because of insufficent content checking by design this opens
a windows of other exploit options.  

This behavior was confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1;
rv:1.7.3) Gecko/20040913 Firefox/0.10, but all versions of Mozilla based
browsers introduce the problem.

Reproducible: Always
Steps to Reproduce:
See details
Actual Results:  
See details

Expected Results:  
See details

Comment 1

[Ben Bucksch (:BenB)]

Not so hard to "find" this bug, this is exactly the kind of stuff that bad guys
try first. I don't think it needs to be hidden.

Comment 2

[Jesse Ruderman]

This is not a content validation problem.

The browser should remain responsive while displaying large files.  But since
this is only a DoS, it shouldn't be security sensitive.

Comment 3

[Peter Kruse]

(In reply to comment #2)
> This is not a content validation problem.
> 
> The browser should remain responsive while displaying large files.  But since
> this is only a DoS, it shouldn't be security sensitive.

Hi!

Does this mean you have decided to make this bug public= If so, I'd like to
advise Full-disclosure about this DoS issue.

Also, this might not be a content validation problem, but it's certainly a
problem, that Mozilla do not look at the content, before opening/viewing it in
the browser. If you try out this trick in IE, you would see, what I consider, a
normal behaviour. IE checks the content and opens the binary with the associated
application (eg. Media player for streams and so on). Binaries are not viewed in
the browser, but instead prompts the user with a warning, as I believe, would be
the proper behaviour. In the same way as Mozilla does when opening exe-files.

Comment 4

[Boris Zbarsky [:bzbarsky]]

IE's behavior is a direct violation of the HTTP specification and leads to
issues in many cases when IE mis-identifies the content.

In particular, it's the source of a number of vulnerabilities in IE.

Since there is no testcase in this bug, and no repeatable steps to reproduce,
marking invalid.  Please file bugs on specific inputs that cause a problem; as
Jesse says we should not hang while rendering them.

Comment 5

[Peter Kruse]

(In reply to comment #4)
> IE's behavior is a direct violation of the HTTP specification and leads to
> issues in many cases when IE mis-identifies the content.
> 
> In particular, it's the source of a number of vulnerabilities in IE.
> 
> Since there is no testcase in this bug, and no repeatable steps to reproduce,
> marking invalid.  Please file bugs on specific inputs that cause a problem; as
> Jesse says we should not hang while rendering them.

Comment 6

[Peter Kruse]

(In reply to comment #5)
> (In reply to comment #4)
> > IE's behavior is a direct violation of the HTTP specification and leads to
> > issues in many cases when IE mis-identifies the content.
> > 
> > In particular, it's the source of a number of vulnerabilities in IE.
> > 
> > Since there is no testcase in this bug, and no repeatable steps to reproduce,
> > marking invalid.  Please file bugs on specific inputs that cause a problem; as
> > Jesse says we should not hang while rendering them.

No testcase, no repeatable steps?

The description of the problem includes a step by step guide to confirm the
problem. Meanwhile, since you made this public, I posted it to full-disclosure
and I've since then received many confirmations of the problem. It's clearly
reproduceable,

Regards
Peter

Comment 7

[Boris Zbarsky [:bzbarsky]]

Peter, I tried this with several binary files and was unable to reproduce.  So
no, your steps to reproduce are not reliable.  Please upload a file that
actually shows the problem (compressed if need be), or point to a URL showing
the problem.

Comment 8

[Peter Kruse]

(In reply to comment #7)
> Peter, I tried this with several binary files and was unable to reproduce.  So
> no, your steps to reproduce are not reliable.  Please upload a file that
> actually shows the problem (compressed if need be), or point to a URL showing
> the problem.

Ok, I've put up a PoC. You can reproduce the problem by visiting the following
URL: http://www.csis.dk/sp3.html

If you let it load for about 20-25 sec. the browser will stop responding.

Regards
Peter

Comment 9

[Frank]

Attachment: Screen dump of the memory use of the Dutch version of Windows XP with this mozilla bug

Screen dump of the memory use of the Dutch version of Windows XP with this
mozilla bug. I have just made this screenshot, no feedback agent popped up, I
just had to kill Mozilla.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Peter, thank you for the testcase.

I let it run for a few minutes.  Mozilla did get very laggy, but it came up for
air every 30 seconds or so, so hitting escape to stop the page load worked. 
Letting it run longer would probably get worse, though, since the time taken to
come back to the event loop is O(N) in the size of the input in this case.

Then I checked out what's actually happening here.  The binary file contains
strings that look like tags ('<' followed by letters), so we ended up creating a
very deep content model, which takes a long time to reflow.  This is a known
problem that can easily be triggered by an actual HTML file, and one of much
smaller size.  So the binary file angle is rather a red herring, in my opinion.

Comment 11

[Jesse Ruderman]

Dup of bug 112738?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Pretty much, yes.

Comment 13

[Jesse Ruderman]

Should I mark it as a dup?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Only if people can't reproduce the crash that was claimed in this bug.  If they
see a crash, I'd like to see the stack or talkback incident id...

Comment 15

[Cavebear42]

Using Peter's link to SP3.html (comment #8) I was able to verify this problem. 
IE 6.0.2900 (the XPSP2 IE) starts displaying junk on the screen (the ASCII
representation of the binary file) and keeps going down the page displaying it
all.  Firefox 1.0PR starts to display this same data but then pegs the cpu to
100% and after a minute or so, freezes.  I have done this on 2 different systems
both with XPSP2.  It appears to me that what IE is doing is processing the data
by chunks and then displaying that data to screen whereas it appear that Firefox
is just streaming the data.  I知 just guessing this based on the way the data is
showing up.  I am not familiar with the Firefox code but it seems to me that if
Firefox was to have a buffer that, once it is done parsing a section of text for
tags, took the new text and appended it to the page in a reasonable size chunk
(that is larger than pages text generally goes) this might solve the problem. 
For instance html >1MB is rare so it appended to screen 1 MB at a time, this
might be what is causing the freeze.<br><br>
At no point in time did either of my systems become unstable nor did it prevent
me from using other apps while it was crunching away in the back ground.<br><br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=112738">bug 112738</a>
refers to valid tags that were not closed correctly and the browser choking
while trying to figure out what to do with all of this text after the valid tag.
 I do not believe that this will be a doup b/c the fix for that will likely be
in the parser and this fix for this will likely be after parsing.<br>

Comment 16

[Boris Zbarsky [:bzbarsky]]

> whereas it appear that Firefox is just streaming the data.

I'm not sure what you mean by this.

> refers to valid tags that were not closed correctly and the browser choking
> while trying to figure out what to do with all of this text after the valid tag

Those tags are just as valid (or not valid) as the "tags" in the binary file
pointed to by the URL field for this bug.

Since no one spoke up about the crash, marking duplicate.

*** This bug has been marked as a duplicate of 112738 ***