610601 - (CVE-2011-0061) Firefox crash [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb] on image with src set to a resource with multipart/x-mixed-replace content type [Access Violation]

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Jordi Chancel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Visiting a webpage that contains an image with the src-attribute that refers to a multipart/x-mixed-replace resource , Firefox 3.6.12 crashes after some time.

Exactly the same as bug 524921

Tested on Windows 7


Reproducible: Always

Steps to Reproduce:
1. Visit test page
2. wait a few moments
Actual Results:  
Firefox crashes

Expected Results:  
Firefox don't crash

The crash is very intermittent , sometimes firefox will crash after some seconds , and sometimes firefox don't crash at all.

Comment 1

[Jordi Chancel]

Attachment: TESTCASE1

Comment 2

[Jordi Chancel]

Attachment: Screenshot [Access Violation]

Comment 3

[Mats Palmgren (inactive)]

Attachment: stack 1.9.2 DEBUG on x86-64 Linux

Comment 4

[Mats Palmgren (inactive)]

Assertions before the crash:
###!!! ASSERTION: number of restored image frames doesn't match the original number of frames!: 'num_expected_frames == mNumFrames', file /usr/moz/1.9.2/modules/libpr0n/src/imgContainer.cpp, line 1651
###!!! ASSERTION: ### nsCacheEntryHashTable::AddEntry - entry already used: '((nsCacheEntryHashTableEntry *)hashEntry)->cacheEntry == 0', file /usr/moz/1.9.2/netwerk/cache/src/nsCacheEntry.cpp, line 465
###!!! ASSERTION: ### Attempting to remove unknown cache entry!!!: 'check == cacheEntry', file /usr/moz/1.9.2/netwerk/cache/src/nsCacheEntry.cpp, line 484

Comment 5

[Mats Palmgren (inactive)]

Stack looks like bug 557107.
There's 4821 crashes in the past 2 week period:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=ycc_rgb_convert&date=11%2F09%2F2010%2002%3A24%3A27&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=ycc_rgb_convert
It's #46 on the Firefox 3.6.11 top crash list.

Comment 6

[Johnny Stenback (:jst)]

Anyone know if this is a branch only crash, or does it happen in 4.0 betas as well?

Comment 7

[Mats Palmgren (inactive)]

There are a few on 4.0b6 too, bp-12007da6-84d7-4f77-845d-fbd9a2101108

Comment 9

[Johnny Stenback (:jst)]

Mats, can you investigate here, or dupe as appropriate...

Comment 10

[Daniel Veditz [:dveditz]]

> Visiting a webpage that contains an image with the src-attribute that
> refers to a multipart/x-mixed-replace resource , Firefox 3.6.12 crashes
> after some time.
>
> Exactly the same as bug 524921

multipart/x-mixed-replace is a red herring. That URL seems to return different (fuzzed?) jpeg images and some of them are tickling bug 557107, which we haven't had a testcase for. Some of the crashes are EXCEPTION_ACCESS_VIOLATION_WRITE so presumably exploitable. the crash reports point at
http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/cd857b3b0e33/jpeg/jdcolor.c#l341

The area around the crashing line was changed as part of bug 411379, may not be part of upstream jpeg.

Changing the keyword from testcase to testcase-wanted because the important bit will be to capture one of the images that trigger the crash.

Comment 11

[Johnny Stenback (:jst)]

Mats, ping?

Comment 12

[Mats Palmgren (inactive)]

Attachment: 1.9.2 stack for failing EnsureCleanFrame

Comment 13

[Mats Palmgren (inactive)]

The problem starts in the crash stack #4, nsJPEGDecoder::OutputScanlines:
http://hg.mozilla.org/mozilla-central/annotate/5ae1f2fa0d9f/modules/libpr0n/decoders/nsJPEGDecoder.cpp#l555
where 'mImageData' is NULL.  I tracked this back to an earlier failure
in EnsureCleanFrame (see 2nd stack), where it tries to reuse a frame
that has no image data.

Comment 14

[Mats Palmgren (inactive)]

Attachment: trunk fix

I don't know this code at all, but I think this should at least avoid the crash.

Comment 15

[Mats Palmgren (inactive)]

Attachment: 1.9.2 fix (same thing)

Comment 16

[Mats Palmgren (inactive)]

It passed TryServer unit tests, builds are here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-d734b25e8af8/

Comment 17

[Joe Drew (not getting mail)]

Comment on attachment 494942 [details] [diff] [review]
trunk fix

It's a bit difficult to imagine how this could happen; I guess if we optimized the surface of the JPEG image.

This is obviously safer, but I think we should also turn off optimizing surfaces in the multipart/x-mixed-replace case. It's ok if you file that as a followup bug and cc bholley and me.

Comment 18

[Mats Palmgren (inactive)]

For the record, this is what 'frame' looked like when GetImageData()
returned the null image data:

$12 = {
  mImageSurface = {
    mRawPtr = 0x0
  }, 
  mOptSurface = {
    mRawPtr = 0x7fffce946500
  }, 
  mSize = {
    width = 640, 
    height = 480
  }, 
  mOffset = {
    x = 0, 
    y = 0
  }, 
  mDecoded = {
    x = 0, 
    y = 0, 
    width = 640, 
    height = 480
  }, 
  mPalettedImageData = 0x0, 
  mSinglePixelColor = {
    r = 0, 
    g = 0, 
    b = 0, 
    a = 0
  }, 
  mTimeout = 100, 
  mDisposalMethod = 0, 
  mFormat = gfxASurface::ImageFormatRGB24, 
  mPaletteDepth = 0 '\000', 
  mBlendMethod = 1 '\001', 
  mSinglePixel = 0 '\000', 
  mNeverUseDeviceSurface = 0 '\000', 
  mFormatChanged = 0 '\000', 
  mCompositingFailed = 0 '\000'
}

Comment 19

[Joe Drew (not getting mail)]

Ah, okay, so this was indeed an optimized image.

Comment 20

[Mats Palmgren (inactive)]

http://hg.mozilla.org/mozilla-central/rev/64e893aa5d95

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 494943 [details] [diff] [review]
1.9.2 fix (same thing)

Approved for 1.9.2.14, a=dveditz for release-drivers

Comment 22

[Daniel Veditz [:dveditz]]

(In reply to comment #17)
> This is obviously safer, but I think we should also turn off optimizing
> surfaces in the multipart/x-mixed-replace case. It's ok if you file that as a
> followup bug and cc bholley and me.

Did the follow up bug happen?

Comment 23

[Mats Palmgren (inactive)]

Filed follow up bug 617651.

Comment 24

[Mats Palmgren (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/804203a74c60

Comment 25

[Al Billings [:abillings - ex-MoCo]]

I haven't been able to replicate the crash on Windows or OS X using the test page pre-fix. Is there a more reliable way of inducing this crash?

Comment 26

[Jordi Chancel]

The crash is very intermittent... but i've got a screenshot of one crash with with a line like 80 80 80 80 [...] before the access violation .
I think it's possible to localize this line on the JPG and maybe do a crash with evidence of corruption resulting in an overflow.

Comment 27

[Jordi Chancel]

Attachment: ScreenShot2

Comment 28

[Al Billings [:abillings - ex-MoCo]]

Jordi, what build and OS were you running this? Was this a post-fix 1.9.2 nightly build?

Comment 29

[Jordi Chancel]

Tested on Windows Seven with Mozilla Firefox 3.6.13

Comment 30

[Jordi Chancel]

the update was for today? =>https://wiki.mozilla.org/Releases

Comment 31

[Mats Palmgren (inactive)]

3.6.14 is delayed due to bug 633869.

Comment 32

[Jordi Chancel]

Have you an idea of the release date?

Comment 33

[Mats Palmgren (inactive)]

Sorry, I don't know.

Comment 34

[Jordi Chancel]

Attachment: ScreenShot3

Comment 35

[Jordi Chancel]

the fix release is for today isn't it? :)

Comment 36

[Al Billings [:abillings - ex-MoCo]]

Yes.

Comment 37

[Mats Palmgren (inactive)]

There are still some related issues with multipart/x-mixed-replace images
that I'm investigating in bug 638018.  Please don't make this bug public
until that bug is.