RE: RE: [VulnWatch] Rendering large binary file as HTML makes Mozilla Firefox stop responding or crash

Peter,

From what I can tell, I'm running XP Pro SP2, IE 6.0 SP2 (though I might be misreading the version number listed in the about internet explorer box),
"Version:6.0.2900.2180.xpsp_sp2_rtm.040803-2158" (simple, right?)
"Update Versions:; SP2;"
It's not likely I'm running an older version than you are.

When I run the binary html file on IE I get the same garbage that is displayed in the Mozilla browser, which should not happen if IE was recognizing it as a binary. Is it possible that some IE setting allows it to make a best guess at the actual file type as opposed to trusting the file extension? I don't think it has anything to do with zones (I ran it locally), because you did the same with the file once it was uploaded to a remote website.

BTW: I ran the same test on a 5MB executable (the Firefox setup program :) and IE was able to load the file as an html (a full page of garbage), and increased memory usage about 20%. After it loaded I was able to close or navigate away from the page easily, and memory returned. When I did the same on Firefox memory usage increased about 60%, and took much longer to load completely. Once it was loaded my system was strained, and closing the page took a long time, and took even longer for the memory to return.

-Troy

-----Original Message-----
From: Peter Kruse [mailto:[email protected]]
Sent: Tuesday, October 26, 2004 9:51 AM
To: Troy Fletcher; [email protected]
Subject: SV: [VulnDiscuss] RE: [VulnWatch] Rendering large binary file
as HTML makes Mozilla Firefox stop responding or crash


Hi Troy,

>I renamed my SP2 executable (big enough? :) to .html and opened it
>up in firefox while watching page fault rate and cpu, and did the
>same with IE. Opening the file in IE was considerably harder on my
>machine than with firefox, both did crash though (or at least
>didn't respond fast enough for windows). Did you do something I
>didn't? I'm sure you tested this with IE, right?

The size of that file should be enough to trigger this flaw. However,
smaller files will also do the trick ;-)
I tested this with no impact on IE 6.0, SP1, running on Windows XP with
Servicepack 2. I was prompted if I wanted to run the executable.

Regards
Peter Kruse


>-----Original Message-----
>From: Peter Kruse [mailto:[email protected]]
>Sent: Monday, October 25, 2004 1:44 AM
>To: [email protected]
>Subject: [VulnWatch] Rendering large binary file as HTML makes Mozilla
>Firefox stop responding or crash
>
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>CSIS Security Advisory: [CSIS2004-5)
>
>Rendering large binary file as HTML makes Mozilla Firefox stop
>responding or
>crash
>
>Date Published: 10.25.2004 (GMT)
>
>Summary
>========
>Mozilla Firefox, Web-browser built for 2004, advanced e-mail and newsgroup
>client, IRC chat client, and HTML editing made simple. The Mozilla Firefox
>shippes with several bugs, making it possible to crash the browser, eat up
>virtual memory, simply by hosting a binary renamed as html, on a remote
>website.
>
>Vulnerability Class
>===================
>The browser should remain responsive while displaying large files. Instead
>it crashes and hangs and feeds on virtual memory which could cause the
>operating system to become unstable.
>
>Details
>=======
>Internet Explorer, and other browsers, verifies the content of filetypes
>before opening in the browser. Based on the content of the file, it decides
>what application should be used to open/view the content of the file. This
>is, by design, not the case with Mozilla based browsers. A
>malicious website
>can host a large chunck of data, spoofed as a html file that Mozilla will
>display within the browser window. Thereby effectively causing a crash on
>systems visiting the website.
>
>You can choose any file from your harddisk larger than 5MB, rename it as a
>html file, upload it to a remote website, or simply open it directly from
>your local harddrive. The result is the same: Mozilla will stop responding,
>showing a lot of binary garbage (clearly understandable), before
>the user is
>forced to either end the application or reboot the system.
>
>In several test scenarios the system force feed all virtual memory causing
>the system to become unstable. However, this all depends on the size of the
>file viewed by the browser. To avoid the user from being suspicious while
>the file loads and garbage is showed in the browser window you can format
>the website in such a way that garbage won't show. This way the
>browser will
>show a blank page until it crashes and the system becomes unstable. When
>viewed, the browser will load the binary without the users knowledge. The
>fact that this bug can be trigged by sending the same file with 1024 ASCII
>characters pre-pended makes exploitation trivial.
>
>Impact
>======
>Low-Medium: This is a remote DoS in Mozilla Firefox. There are
>several other
>ways to crash the browser.
>
>This behavior was confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1;
>rv:1.7.3) Gecko/20040913 Firefox/0.10, but my guess is that all versions of
>Mozilla introduce the problem.
>
>Solution
>=========
>Awaiting fix
>
>Affected Products
>================
>Mozilla/5.0 Gecko/20040913 Firefox/0.10 and prior
>
>
>- ---
>
>Med venlig hilsen // Kind regards
>
>Peter Kruse,
>Security- and virusanalyst,
>CSIS ApS
>http://www.csis.dk
>
>PGP fingerprint
>79FD 0648 158E 6B9E 236F  CFDA 7C58 64D6 BE83 FA60
>
>Combined Services & Integrated Solutions
>Gevnø Gade 11a
>4660 Store Heddinge, Denmark
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 8.1
>
>iQA/AwUBQXy8J3xYZNa+g/pgEQLy1gCeIOBSUFvWcMDxRdctMJKZyepxBuUAn0cs
>2AJ7hwekVBENB2m1+t5CoQ26
>=Mi5B
>-----END PGP SIGNATURE-----
>
>