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

(4 keywords, 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?]
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+
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.

Attachment

General

Creator:
Created:
Updated:
Size: