153621 - Browser crashes when viewing a bad image....

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Al Davis]

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.

Comment 1

[Moiz Dohadwala]

wfm win2k, sp2, mozilla 1.1a 2002061104

Comment 2

[Andrew Schultz]

Attachment: stacktrace

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?

Comment 3

[Andrew Schultz]

marking NEW

Comment 4

[Richard Godbee]

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.

Comment 5

[ArronM (:paper)]

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.  

Comment 6

[Andrew Schultz]

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

Comment 7

[ArronM (:paper)]

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

Comment 8

[Andrew Schultz]

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

Comment 9

[tenthumbs]

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.

Comment 10

[Andrew Schultz]

OS => Linux to get more attention

Comment 11

[Jo Hermans]

see bug 243493

Comment 12

[Wayne Mery (:wsmwk)]

lacks testcase - http://img.hostinghive.com/mozilla/bad_img.jpg is no longer available

(this bug was referred to in Bug 166862)

Comment 13

[Hermann Schwab]

(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

Comment 14

[Wayne Mery (:wsmwk)]

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