Closed Bug 374810 (CVE-2007-2445) Opened 13 years ago Closed 13 years ago

Crash [@ MOZ_PNG_init_read_transf] with png image

Categories

(Core :: ImageLib, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9alpha8

People

(Reporter: martijn.martijn, Assigned: glennrp+bmo)

References

()

Details

(4 keywords, Whiteboard: [sg:dos])

Crash Data

Attachments

(2 files, 1 obsolete file)

When trying to open this image, Mozilla crashes.
It also happens in Mozilla1.7.13 and other branches, so I'm filing this as security sensitive, just to be sure.

Talkback ID:
MOZ_PNG_init_read_transf  [mozilla/modules/libimg/png/pngrtran.c, line 816]
MOZ_PNG_read_start_row  [mozilla/modules/libimg/png/pngrutil.c, line 3156]
MOZ_PNG_read_update_info  [mozilla/modules/libimg/png/pngread.c, line 628]
MOZ_PNG_push_have_info  [mozilla/modules/libimg/png/pngpread.c, line 1710]
MOZ_PNG_proc_some_data  [mozilla/modules/libimg/png/pngpread.c, line 55]
nsPipeInputStream::ReadSegments  [mozilla/xpcom/io/nspipe3.cpp, line 766]
nsPNGDecoder::WriteFrom  [mozilla/modules/libpr0n/decoders/png/nspngdecoder.cpp, line 259]
imgRequest::OnDataAvailable  [mozilla/modules/libpr0n/src/imgrequest.cpp, line 903]
png_ptr->num_trans is 1 but png_ptr->trans is null, so dereferencing png_ptr->trans[i] crashes.

How did we get in that state? If num_trans and trans can get out of sync there might be ways to get trans set to a non-null value. Are we trusting the image data without validation?
Assignee: nobody → vladimir
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.9?
Whiteboard: [sg:investigate]
Also occurs on Linux.
OS: Windows XP → All
Attached patch wip (obsolete) — Splinter Review
I think the bug is in png_handle_tRNS:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libimg/png/pngrutil.c&rev=3.13&root=/cvsroot&mark=1309,1318,1319,1321#1288

We set "png_ptr->num_trans" to 1 at line 1309 (ok), but then
there is a CRC error detected on line 1318 and we return
early - it is png_set_tRNS() at the end that allocates
the 'trans' buffer.

FYI, this patch makes us display some kind of fallback image
that says we don't support APNG. I'm not sure if that's the
expected result.
I also looked briefly at png_set_tRNS.
It does not seem to handle OOM very well...
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libimg/png/pngset.c&rev=3.11&root=/cvsroot&mark=927,930,932,934,942,943,946#909

We should probably set num_trans=0 here and not set the
FREE_TRNS flag and not set info_ptr->valid bit if OOM occurs.
Clamping num_trans to PNG_MAX_PALETTE_LENGTH in png_set_tRNS wouldn't
hurt too...
It might be worth asking the libpng people since this is an external library?
Ah sorry, maybe this is basically what bug 373249 is about?
bug 373249 looks different, I don't think it's related to this bug.
Flags: blocking1.9? → blocking1.9+
-> Mats, I know nothing about this
Assignee: vladimir → mats.palmgren
Target Milestone: --- → mozilla1.9beta1
Cannot figure out how to download the image.  Firefox crashes, Seamonkey
crashes and takes the windows display driver with it.  Lynx and IE can't
get past the "proceed" button.
The patch seems correct.  Here is an updated patch that also updates MOZCHANGES and sets the minimum system libpng to 1.2.17 which will be released next week with the patch, and uses the bracketing style of libpng.
Assignee: mats.palmgren → glennrp
Attachment #259303 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(In reply to comment #0)
> When trying to open this image, Mozilla crashes.
> It also happens in Mozilla1.7.13 and other branches, so I'm filing this as
> security sensitive, just to be sure.

The vulnerability has existed in libpng since version 0.90 so it will affect
all versions of gecko, whether they use the system libpng or the embedded one.
Comment on attachment 263854 [details] [diff] [review]
patch for 1.8 branch (checked in to branch)

> dnl Set the version number of the libs included with mozilla
> dnl ========================================================
> MOZJPEG=62
>-MOZPNG=10207
>+MOZPNG=10217

This doesn't seem right, fixing this bug does not take us to 1.2.17
*on the branches* which is lacking (most of) the changes from 1.2.7
to 1.2.16, right?

Looks good otherwise, also for the 1.8.0 branch.
(In reply to comment #14)


> This doesn't seem right, fixing this bug does not take us to 1.2.17
> *on the branches* which is lacking (most of) the changes from 1.2.7
> to 1.2.16, right?

See discussion in bug #373249.  Security-wise, the branch is at the same
level as trunk, except for some additional tests for NULL pointers on
the trunk.  But this bug casts a new light on the situation.  Unpatched
system libraries through 1.2.16 are vulnerable to a simple attack via
a PNG with a malformed tRNS chunk.  We don't have a way of detecting
whether the system library has been patched.  Of course they are all
unpatched now because we haven't released the patch yet (I've reported
it to CERT but have not heard back from them).
Ok, that bug explains it, thanks.
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.4?
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.12?
Comment on attachment 263849 [details] [diff] [review]
bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)

Tor: r?
Attachment #263849 - Flags: review?(tor)
Comment on attachment 263854 [details] [diff] [review]
patch for 1.8 branch (checked in to branch)

tor: r for branch?
Attachment #263854 - Flags: review?(tor)
(In reply to comment #15)
>(I've reported
> it to CERT but have not heard back from them).

Still no word from CERT.  Silly me forgot they are paid to respond and
therefore won't look at it until the next work day.

We should probably coordinate the release of the mozilla patch with
the libpng-1.2.17 release.
If this doesn't make 1.8.1.4/1.8.0.12 then the next planned release is 1.8.1.5 in July. Can this wait, or should we squeeze it into 1.8.1.4 ahead of any coordination (and not announce anything).

What "new light" (comment 15) does this bug cast? It still looks like a null deref which we can live with. I guess the size of num_trans is under the control of the attacker, but there's at least one check that it's <= 256 which doesn't get an attacker into the heap on most OS's.
"new light" is as I said in comment #10, seamonkey crashes and takes my
windows display with it.  Throws my screen into "safe" mode.

I doubt that an attacker could use it to break into a system or to elevate
priveleges.  This is probably only a Denial of Service problem.

This is new because it can be caused by a malformed PNG image on a web site.
The other NULL problems are only due to application programming errors,
which gecko/libpr0n doesn't have.

The erroneous num_trans can only be "1".

I still haven't heard from CERT (guess they don't come in early on Mondays) but suspect they will ask for 45 days.  I don't have a problem with releasing a change without anouncing why.
I just now heard from CERT:

Thank you for the report, we are tracking this as VU#684664. We will follow up with our established contacts at libpng.

Attachment #263849 - Flags: review?(tor) → review+
Attachment #263854 - Flags: review?(tor) → review+
Comment on attachment 263849 [details] [diff] [review]
bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)

sr anyone?
Attachment #263849 - Flags: superreview?
Attachment #263854 - Flags: superreview?
(In reply to comment #3)

> FYI, this patch makes us display some kind of fallback image
> that says we don't support APNG. I'm not sure if that's the
> expected result.

Yes, I see that, too, with the patch and also with a MNG-supporting
build that does not use libpng and is therefore not vulnerable.  That
is correct behaviour for the MNG-supporting build but I'm not sure why
the patched one does not show the APNG animation.

Here's a "pngcrush -fix -v" report:

Reading IHDR chunk, length = 13.
Reading PLTE chunk, length = 48.
Reading tRNS chunk, length = 1.
libpng warning: [00][00][00][00]: CRC error
Reading bKGD chunk, length = 1.
Reading acTl chunk, length = 16.
Reading IDAT chunk, length = 2386.
Reading fcTl chunk, length = 25.
Reading tIME chunk, length = 7.
Reading fdAt chunk, length = 2554.
Reading fcTl chunk, length = 25.
Reading fdAt chunk, length = 2579.
[etc]

Hmmm, the chunk names are wrong (should end with L and T not l and t)
so that explains why we see the fallback.  It's proper behaviour.

I received a request to use CVE name CVE-2007-2445 for this issue
Hardware: PC → All
Alias: CVE-2007-2445
Whiteboard: [sg:investigate] → [sg:nse dos]
(In reply to comment #20)
> If this doesn't make 1.8.1.4/1.8.0.12 then the next planned release is 1.8.1.5
> in July.

When are 1.8.1.4/1.8.0.12 due out?  I've spoken with CERT and they don't
have a problem with a quick release, e.g., May 15th, with an announcement.

I was planning to release libpng-1.2.17 on May 12 but it's no problem waiting
until May 15 or so.

CERT is pretty much leaving it up to us when to disclose/release.
Libpng-1.2.17, with the patch and a security advisory, will be released
tomorrow, May 15th, at noon EST.
If anyone here has sr privileges, please do the superreviews.
Comment on attachment 263849 [details] [diff] [review]
bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)

sr=dveditz
Attachment #263849 - Flags: superreview? → superreview+
Comment on attachment 263854 [details] [diff] [review]
patch for 1.8 branch (checked in to branch)

sr=dveditz
Attachment #263854 - Flags: superreview?
Attachment #263854 - Flags: superreview+
Attachment #263854 - Flags: approval1.8.1.5?
Attachment #263854 - Flags: approval1.8.0.13?
The libpng release is delayed from noon until 4:00 PM EST tomorrow, May 15.
Oops, EDT not EST.
Libpng-1.2.17 has been released.
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.1.4?
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Flags: blocking1.8.0.12?
Comment on attachment 263854 [details] [diff] [review]
patch for 1.8 branch (checked in to branch)

approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers
Attachment #263854 - Flags: approval1.8.1.5?
Attachment #263854 - Flags: approval1.8.1.5+
Attachment #263854 - Flags: approval1.8.0.13?
Attachment #263854 - Flags: approval1.8.0.13+
fix landed on branches
fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
verified fixed 1.8.1.5 using  Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8.1.5pre) Gecko/2007071216 BonEcho/2.0.0.5pre and Mozilla/5.0 (Windows; U;
Windows NT 6.0; en-US; rv:1.8.1.5pre) Gecko/2007071216 BonEcho/2.0.0.5pre also
a mac build with this testcase - no crash on testcase - adding verified keyword
Someone please clear the security-sensitive flag.
Group: security
Flags: in-testsuite?
also no crash with thunderbird 1.5.0.13 with thunderbrowse. Thunderbrowse mark this url as too long.
verified fixed 1.8.0.13 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.13pre) Gecko/20070822 Firefox/1.5.0.13pre - no crash on test url
adding verified keyword
Attachment #263849 - Attachment description: bugfix, MOZCHANGES, minimum system library 1.2.17 → bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)
Attachment #263854 - Attachment description: patch for 1.8 branch → patch for 1.8 branch (checked in to branch)
crash test landed
http://hg.mozilla.org/mozilla-central/rev/90a53b9435a4
Flags: in-testsuite? → in-testsuite+
Whiteboard: [sg:nse dos] → [sg:dos]
Crash Signature: [@ MOZ_PNG_init_read_transf]
You need to log in before you can comment on or make changes to this bug.