The default bug view has changed. See this FAQ.
Bug 374810 (CVE-2007-2445)

Crash [@ MOZ_PNG_init_read_transf] with png image

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
ImageLib
--
critical
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: Glenn Randers-Pehrson)

Tracking

(4 keywords)

Trunk
mozilla1.9alpha8
crash, testcase, verified1.8.0.13, verified1.8.1.5
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.5 +
wanted1.8.1.x +
blocking1.8.0.13 +
wanted1.8.0.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos], crash signature, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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]

Comment 2

10 years ago
Also occurs on Linux.
OS: Windows XP → All

Comment 3

10 years ago
Created attachment 259303 [details] [diff] [review]
wip

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.

Comment 4

10 years ago
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.

Comment 5

10 years ago
Clamping num_trans to PNG_MAX_PALETTE_LENGTH in png_set_tRNS wouldn't
hurt too...

Comment 6

10 years ago
It might be worth asking the libpng people since this is an external library?
(Reporter)

Comment 7

10 years ago
Ah sorry, maybe this is basically what bug 373249 is about?

Comment 8

10 years ago
bug 373249 looks different, I don't think it's related to this bug.

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
-> Mats, I know nothing about this
Assignee: vladimir → mats.palmgren
Target Milestone: --- → mozilla1.9beta1
(Assignee)

Comment 10

10 years ago
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.
(Assignee)

Comment 11

10 years ago
Created attachment 263849 [details] [diff] [review]
bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)

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
(Assignee)

Comment 12

10 years ago
Created attachment 263854 [details] [diff] [review]
patch for 1.8 branch (checked in to branch)
(Assignee)

Comment 13

10 years ago
(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.
(Assignee)

Comment 15

10 years ago
(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?
(Assignee)

Comment 17

10 years ago
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)
(Assignee)

Comment 18

10 years ago
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)
(Assignee)

Comment 19

10 years ago
(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.
(Assignee)

Comment 21

10 years ago
"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.
(Assignee)

Comment 22

10 years ago
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.

Updated

10 years ago
Attachment #263849 - Flags: review?(tor) → review+

Updated

10 years ago
Attachment #263854 - Flags: review?(tor) → review+
(Assignee)

Comment 23

10 years ago
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?
(Assignee)

Updated

10 years ago
Attachment #263854 - Flags: superreview?
(Assignee)

Comment 24

10 years ago
(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.

(Assignee)

Comment 25

10 years ago
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]
(Assignee)

Comment 26

10 years ago
(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.
(Assignee)

Comment 27

10 years ago
Libpng-1.2.17, with the patch and a security advisory, will be released
tomorrow, May 15th, at noon EST.
(Assignee)

Comment 28

10 years ago
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?
(Assignee)

Comment 31

10 years ago
The libpng release is delayed from noon until 4:00 PM EST tomorrow, May 15.
(Assignee)

Comment 32

10 years ago
Oops, EDT not EST.
(Assignee)

Comment 33

10 years ago
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
Keywords: fixed1.8.0.13, fixed1.8.1.5
fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 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
Keywords: fixed1.8.1.5 → verified1.8.1.5
(Assignee)

Comment 38

10 years ago
Someone please clear the security-sensitive flag.
(Reporter)

Updated

10 years ago
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
Keywords: fixed1.8.0.13 → verified1.8.0.13
(Assignee)

Updated

10 years ago
Attachment #263849 - Attachment description: bugfix, MOZCHANGES, minimum system library 1.2.17 → bugfix, MOZCHANGES, minimum system library 1.2.17 (checked in to trunk)
(Assignee)

Updated

10 years ago
Attachment #263854 - Attachment description: patch for 1.8 branch → patch for 1.8 branch (checked in to branch)

Comment 41

8 years ago
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.