435130 - (CVE-2008-2419) Firefox Heap Corruption

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[Asa Dotzler [:asa]]

http://www.0x000000.com/?i=576

Okay, onwards with heap fun.

I forgot to tell you all about this actually. I found this about 8 months back and never discussed it for various reasons. Since I saw that Mozilla has fixed a lot of memory leaks inside Firefox 2/3, I guess it's safe to say I can talk about this now. Still it works in the latest Firefox build. So, what is going on? Well, I found out that when you utilize the document.open, document.write, and document.close procedure by writing into an Iframe, it usually runs into trouble when a block of code fails to execute between writing in the JSframe and closing the JSframe. Sounds plausible so far I guess, but it's more interesting when you use an empty applet. An empty applet fails to load and therefore the JSframe can't close the writing procedure since Firefox already closed it because of the applet failing -or- because there are instructions being written to the heap due to Java memory allocation, on the same time Javascript tries to close the Iframe. That results into the problem that the parent JS thread still tries to close the iframe -since that was the instruction- but can't :) which in terms eats it's way on the heap, because it's running multiple instructions in a process -which heaps are for eh- which then results in possible invalid memory I figured, then gives up and goes into reverse. ;)

When executing the example below, it tries to load the applet, runs into memory and fails to close. In my test environment the browser becomes unresponsive and text being typed in the url-bar is reversed. If I let it run a couple of minutes, or try to navigate it results into a heap corruption, for God knows what. Anyway, I am too lazy to perform a stack trace, I'll leave that as an exercise for you, and also because my current copy of AutoDebug has expired :) Heap corruptions are usually very serious but hard to exploit correctly, because if controlled properly it can be used to execute code on a users system. I won't go into that because I simply don't have the time, concentration nor interest for it. So bear with me on this one, I might do an article on this in the near future.

<script>
// It might not work on your platform due to a ton of reasons.
// tested on WinXP SP2 JRE version 1.6.0_01

function run() {
	var data = '<applet src="javascript:" id="x">';
	y.document.open();
	y.document.write(data);
	y.document.close()
}

</script>
<input name="button" value="Run" onclick="run()" type="button">
<iframe name="y" id="x" src="" frameborder="1" height="200"></iframe>

Comment 1

[Brandon Sterne (:bsterne)]

I tested this on Mac 10.5 and Windows XP SP2 with JRE 1.6.0_05-b13, both branch and trunk.  In all cases the "applet" simply fails to load.  What else should I be looking for that would indicate heap corruption?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

I can confirm that the site crashed the hell out of my browser. Are we sure that this isn't caused by a plugin?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Bah, sorry, ignore comment 2 - wrong bug :(

Comment 4

[Johnny Stenback (:jst)]

I tested this on Vista with SE 6 U10 and I'm not able to see a problem here :(

Comment 5

[Steven Michaud [:smichaud] (Retired)]

See bug 432743 for a possibly related bug.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can't reproduce this either, I have Win XP SP2 and JRE 1.6.0_30

Comment 7

[Daniel Veditz [:dveditz]]

And I tried JRE 1.6.0_01, 1.6.0_03, 1.6.0_05 and 1.6.0_06 on WinXP SP2.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Dan, I take it you couldn't reproduce with any of those JREs?

Comment 9

[Daniel Veditz [:dveditz]]

right, never crashed

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this INVALID, then?

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd say it's INCOMPLETE as there might be more information needed in order to trigger this.

Comment 12

[Daniel Veditz [:dveditz]]

This was apparently assigned CVE-2008-2419, adding for future reference.