User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 When an image that has been included inline as an object is above a certain size threshhold, bringing up the Element Properties dialog box (right click and select Properties from the context menu) causes the entire system to hang. A slightly smaller image does not cause this to happen. As far as I can tell, the threshhold above which this occurs is somewhere around 48KB. It appears that since the data attribute of the object tag is used as the "location" of the element, more than 48K of data causes a buffer to overflow when the location is displayed in the Element Properties dialog. The Media tab of the Page Info is similarly affected. Reproducible: Always Steps to Reproduce: 1. Load http://jon.x13designs.com/firefox_crash.html 2. Right click on the second image (the one with the geometric shapes). 3. Select Properties from the context menu. Actual Results: The Element Properties dialog pops up, but without any controls rendered. At this point, the entire system is completely locked up. Expected Results: The Element Properties dialog should open. I am marking this a security problem since it appears that the problem is a buffer overflow.

I'm not seeing a problem on winXP. How much memory do you have? If you bring up the task manager does it look like memory consumption could be part of the problem?

The machine has 1GB of memory. It is impossible to view memory usage after this happens - the entire system is completely frozen. I tried this at home on my Linux machine and was also unable to reproduce. Could it be specific to Win2k?

I can't reproduce this on Win2K, with today's nightlies on both the branch (1.0.6 essentially) and the trunk. No crash or any sluggishness at all. The "address" field obviously contains a great deal of overlapping information, but all works well.

I've been able to reproduce this consistently on my Win2K machine, with 1.04, 1.05, various nightly builds, and builds that I've made. I imagine that this is more an operating system problem than anything to do with Firefox. To wit, I've made a patch that prevents this from happening, in effect hiding the underlying problem, wherever it may be. It truncates the image URL in the Element Properties and the Page Info dialogs to be no more than 2^15 characters.

Comment on attachment 189795 [details] [diff] [review] Patch to truncate image URL in Page Info and Element Properties dialogs Should this really be security sensitive? It's just a crash. Is there any possible way to exploit this to do anything but crash when an obscure menu option is used? I still can't reproduce this, but I'm requesting review so the patch gets on the radar for someone to take a look at.

I asked several people on #bs to test this for me. * DeltaF is using Windows 2000. He tested (both image properties and Page Info) and didn't get a crash. * Tristor is using Windows 2000. He was able to open task manager and kill Firefox, but the system remained laggy, and eventually froze when he tried to open the Start menu to restart the compupter. He ended up unplugging the computer to restart it. Since this crashes in both Element Properties and Page Info, a remote XUL page containing the same XUL (the most important part being a very long string with no line breaks) would probably crash as well. Tristor, want to try making a simple XUL testcase? ;)

(In reply to comment #7) > I asked several people on #bs to test this for me. > > * DeltaF is using Windows 2000. He tested (both image properties and Page Info) > and didn't get a crash. > > * Tristor is using Windows 2000. He was able to open task manager and kill > Firefox, but the system remained laggy, and eventually froze when he tried to > open the Start menu to restart the compupter. He ended up unplugging the > computer to restart it. > > Since this crashes in both Element Properties and Page Info, a remote XUL page > containing the same XUL (the most important part being a very long string with > no line breaks) would probably crash as well. Tristor, want to try making a > simple XUL testcase? ;) Unfortunately I don't know XUL, so I probably can't make a good testcase. Just FTR, the UA string for my earlier testing is Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 I will attempt to reproduce in Deer Park Alpha 2 in a moment.

Last night, while in #bs with Jesse, I tried to reproduce the system lockup the second time around, I am not sure why but it did not happen under identical conditions to my first reproduction. I got the info box as expected with a truncated URL (both under the media tab on page info and under the element properties dialog). I am going to try fiddling with it later today to see if I can't make it lockup again.

Unfortunately the original testcase URL no longer works, I'll attach what I believe to be a testcase for this bug in a moment.

This is an <object> with a large data: URI in the data: attribute.

It would be great if someone could test this with a current trunk build on Windows (2000 or otherwise).

Can we get someone to confirm that this bug still happens? Tristor confirmed the bug briefly but hasn't been able to reproduce it since.

Current Firefox versions (4 and later) don't have the Properties dialog. 3.6 still had a View Image Info dialog that might have had the same issue, but even that's gone now.