Closed Bug 321223 Opened 16 years ago Closed 16 years ago

Giant images exploitable as DoS attack

Categories

(Core :: ImageLib, defect)

1.7 Branch
x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 213391

People

(Reporter: rhamph, Assigned: pavlov)

Details

(Keywords: hang, Whiteboard: [sg:dos] DUPEME)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)

Bug 213391 can be easily exploited as a DoS attack.  Use GIMP to create a 3000x3000 1-bit image, save as PNG with max compression, result is a 3839 byte file.  Loaded in firefox this takes 36 megabytes in the X server.  One such image is okay, but copy it 10 or 100 times and put them all on one page, now you've got a Thrash of Death (http://everything2.com/index.pl?node_id=883540).

Linux is atleast partly to blame, since only it can make the entire OS unusable.  Still, firefox should not be using unbounded amounts of memory to begin with.

This does not seem easily exploitable with gmail's webmail interface, as it creates small thumbnails, but I do not use Thunderbird so I cannot test it.

Note that the naive approach of only decompressing on-screen images is not sufficient as a single image could be created that would be large enough to invoke the DoS (if you can avoid getting Thrash of Death from The GIMP).  Even if not that there's various other ways to get many images to count as "on-screen".  Many overlapping layers seems to be the worst.  I see no easy solutions.

Reproducible: Always

Steps to Reproduce:
Note that it is safe to view this image by itself, as it only uses 36 megabytes in the X server.  This can be verified with xrestop.
Assignee: nobody → pavlov
Component: General → ImageLib
Keywords: hang
Product: Firefox → Core
QA Contact: general
Whiteboard: [sg:dos]
Version: unspecified → 1.7 Branch
can we please declassify and resolve this bug as a duplicate?
Whiteboard: [sg:dos] → [sg:dos] DUPEME
If the policy is that DoS bugs aren't security-sensitive then I'm not opposed to declassifying and resolving as a duplicate.

Or perhaps it's because there's already an unclassified report on the same bug, even though it doesn't discuss the DoS potential?  I'm still fine with declassifying and resolving it as a duplicate in that case.
Group: security

*** This bug has been marked as a duplicate of 213391 ***
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.