Closed Bug 610601 (CVE-2011-0061) Opened 14 years ago Closed 14 years ago

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]

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
status1.9.2 --- .14-fixed
status1.9.1 --- unaffected

People

(Reporter: jordi.chancel, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: crash, testcase, topcrash, Whiteboard: [sg:critical?])

Crash Data

Attachments

(6 files, 2 obsolete files)

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.
Attached file TESTCASE1
Attached image Screenshot [Access Violation] (obsolete) —
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
Status: UNCONFIRMED → NEW
Component: General → ImageLib
Ever confirmed: true
Keywords: crash, testcase
OS: Windows 7 → All
QA Contact: general → imagelib
Hardware: x86 → All
Whiteboard: [sg:critical?]
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.
Keywords: topcrash
Summary: Firefox crash on image with src set to a resource with multipart/x-mixed-replace content type [Access Violation] → 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]
Anyone know if this is a branch only crash, or does it happen in 4.0 betas as well?
There are a few on 4.0b6 too, bp-12007da6-84d7-4f77-845d-fbd9a2101108
Mats, can you investigate here, or dupe as appropriate...
Assignee: nobody → matspal
> 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.
Mats, ping?
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.
Attached patch trunk fixSplinter Review
I don't know this code at all, but I think this should at least avoid the crash.
Attachment #494942 - Flags: review?(bobbyholley+bmo)
Attachment #494942 - Flags: review?(bobbyholley+bmo) → review?(joe)
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.
Attachment #494942 - Flags: review?(joe) → review+
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'
}
Attachment #494942 - Flags: approval2.0?
status1.9.2: --- → ?
Ah, okay, so this was indeed an optimized image.
Attachment #494942 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/64e893aa5d95
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Attachment #494943 - Flags: approval1.9.2.14?
Comment on attachment 494943 [details] [diff] [review]
1.9.2 fix (same thing)

Approved for 1.9.2.14, a=dveditz for release-drivers
Attachment #494943 - Flags: approval1.9.2.14? → approval1.9.2.14+
(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?
Filed follow up bug 617651.
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?
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.
Attached image ScreenShot2 (obsolete) —
Jordi, what build and OS were you running this? Was this a post-fix 1.9.2 nightly build?
Tested on Windows Seven with Mozilla Firefox 3.6.13
Alias: CVE-2011-0061
the update was for today? =>https://wiki.mozilla.org/Releases
3.6.14 is delayed due to bug 633869.
Have you an idea of the release date?
Sorry, I don't know.
Attachment #489118 - Attachment is obsolete: true
Attachment #502194 - Attachment is obsolete: true
Attached image ScreenShot3
the fix release is for today isn't it? :)
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.
Group: core-security
Crash Signature: [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb]
Crash Signature: [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb] → [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb]
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.