From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020619 BuildID: 00000000 I've managed to capture a bogus image that doesn't contain any valid image data, as far as I can tell, but it's something that I ran across on my free host and tracked down because it was crashing my browser every time I'd view the image. To me this would make a nifty DoS or possibly worse, but I'm not sure how to exploit the vulnerability. Reproducible: Always Steps to Reproduce: 1.Open Mozilla 2.View the image in the URL. I can produce more images if you'd like. Actual Results: My browser completely closes/crashes w/o a core dump. <:~( Expected Results: Shown a broken image or shown the default text, "this image contains no valid data" Please feel free to ask me any questions or for more samples, I've got a whole free host full of 'em.

wfm win2k, sp2, mozilla 1.1a 2002061104

stacktrace shows it trying to allocate memory for an image of 20486x24580 (x3 bytes/pixel), roughly 1.5GB. That results in an instant abort. Perhaps an image size sanity check?

marking NEW

WFM, 2002061408 trunk/WinNT. Browser displays the (unselectable/uncopyable) text: The image ``http://img.hostinghive.com/mozilla/bad_img.jpg'' cannot be displayed, because it contains errors.

Al, what version of gcc are you using? I read that some gcc version 2.95.x's (or before) improperly throw an abort when allocating memory.

I was using gcc-2.96-110. Mozilla-built binaries use egcs-1.1.2

Unfortunately I'm not a gcc or BSD expert, but the article I ran accross that looked similar to this problem is http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00550.html

Mozilla's code does not seem to use "set_new_handler" I was actually running under Linux (RH73) instead of FreeBSD

I believe this bug is really about how an OS handles allocation requests and exception handling if such a request fails. Windows generally uses a dynamically-sized virtual memory so almost any request, no matter how ridiculous, succeeds initially. Windows may get into trouble later if it can't grow it's swap file large enough and may crash. This doesn't happen here because the image really is corrupt internally. I'll bet mozilla requests the huge size but shortly see the image is bad and throws everything away so there's no harm done. Linux/Unix usually use a fixed-sized virtual memory so any request that's significantly larger that the available vm fails. Here's where the exception handling comes in. In C++ the libraries throw a bad_alloc exception and the default handler has no idea what's going on and does the safest thing which is to abort the process. This is fairly standard practice. Here, the request for 1.5GB fails immediately and the default handler clobbers mozilla. This doesn't seem to depend on compiler. On Linux I tried everything from egcs 1.1.2 on up and they all work the same way. A failed operator new[] call with a default handler always aborts. Right now mozilla just assumes all allocations always succeed. It needs to install exception handlers or perhaps overload operator new[]. Mozilla also needs to decide if a image is just too large to open. The jpeg library permits up to 65500x65500 so that times 4 is nearly 16GB which is too large for any 32-bit system.

OS => Linux to get more attention

see bug 243493

lacks testcase - http://img.hostinghive.com/mozilla/bad_img.jpg is no longer available (this bug was referred to in Bug 166862)

(In reply to comment #12) > lacks testcase - http://img.hostinghive.com/mozilla/bad_img.jpg is no longer > available > > (this bug was referred to in Bug 166862) > testcase Attachment 148399 [details] bad_img.bmp (2.41 KB, application/octet-stream) attached to Bug 243493 – Crash when opening bogus BMP file WFM after downloading and opening locally Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008080300 SeaMonkey/2.0a1pre Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Antivirus flagged the image so not testing here. => WFM per comment 13