214146 - Browser thrashes on 160k PNG file

Status: RESOLVED INCOMPLETE

(Core :: Graphics: ImageLib, defect)

Description

[Paul Rubin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

This file is a scan of a hand drawn circuit diagram, 5k*4k resolution.  It's
just 160k but the browser thrashes like crazy trying to load it.  My whole
system becomes unuseable (750 mhz PIII, 256 meg ram, RH 9.0)--mouse responds
very slowly and machine thrashes its brains out.  

Reproducible: Always

Steps to Reproduce:
1. Visit URL pasted above
2.
3.

Actual Results:  
Browser and machine thrash while trying to display the 20 megapixel file.  Note,
the file is viewable in Gimp.  Gimp also thrashes but not as badly as Mozilla. 
It's possible that if you test on a bigger/faster machine it won't thrash as bad.

Expected Results:  
Hard to say.  Decide not to load the image, maybe.  Or scale it to a reasonable
size before displaying.  Or load it in a way that doesn't thrash--I suspect it's
being internally decompressed to hundreds of MB even though with 20 megapixels
and 4 bytes/pixels it should need 80 MB at worst.


I'm checking this as a security bug because it creates a bad DOS attack
(attacker can make a tiny PNG that expands to a 100 megapixel image) but use
your judgement and uncheck it if you think it shouldn't be marked that way.

Although Mozilla effectively hangs because of this bug, I checked it as "Major"
rather than "Critical" because there aren't so many such images out there.  This
is my first encounter with one.  Maybe it should be downgraded to Normal.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

We generally don't treat one-off DoS attacks (like this) as security bugs,
because the user can generally avoid them easily in the future (found bad page?
don't go there). If this could be used to make it so the user ALWAYS encounters
this and there is no easy/obvious ways to work around it, then I'd say keep it
security sensitive.

Based on the above, I suggest we open this to the public. What do you think?

Comment 2

[Daniel Veditz [:dveditz]]

Could a PNG be constructed that is much smaller, say 20K, but still causes
equivalent thrashing? In that range it could easily be spammed as a widespread
e-mail DOS.

Comment 3

[tor]

A 8K x 8K pure red PNG file takes only about 8KB of space, and will cause
mozilla to grab 192MB of memory for the image buffer, plus whatever the
platform gfx decides to use.

There is a limit for the size of the image, but it was added to prevent
wraparound conditions -
http://lxr.mozilla.org/seamonkey/source/gfx/src/shared/gfxImageFrame.cpp#28
.

The problem with adding a limit is where to place it.  What might be a massive
image to an ordinary user might be trivially small to NASA, for example.

Comment 4

[Paul Rubin]

I think NASA would not send around huge images that compressed to tiny ones.  A
reasonable rule might be don't expand images > 20 MB unless the file generating
them is at least 1/10th the size of the expanded image, or the user clicks on a
warning dialog.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I have a hard time believing we don't have an equivalent old bug for gifs...

Th real problem here, of course, is that on Linux it's not really possible to
handle OOM conditions.  If the OS were sane, it would tell us we can't have that
much memory and we would just not show that image.  But it decides to kill off
the process instead.  :(

Comment 6

[Paul Rubin]

The browser isn't really running out of memory.  It's allocating an amount of
virtual memory that's within bounds.  That just happens to make it thrash like
crazy.  Some kind of browser hack to deal with this situation really does seem
appropriate.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm... If we don't crash, then why is this a security-sensitive bug?  The same
problems could happen as a result of anything that generates huge documents (eg
client-side JS or gzip-encoded large HTML or text files with very compressible
text).

Comment 8

[chris hofmann]

anyone on the cc want to pick up this bug from jdunn?

Comment 9

[Daniel Veditz [:dveditz]]

*** Bug 289864 has been marked as a duplicate of this bug. ***

Comment 10

[Daniel Veditz [:dveditz]]

Clearing security flag, obscurity isn't helping any here.

Comment 11

[Alfred Kayser]

Can we close this one as 'INCOMPLETE' or 'INVALID' as the original image is gone, and the latest comment beside bugzilla spam is 8 years ago.