The default bug view has changed. See this FAQ.
Bug 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]

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
ImageLib
--
critical
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: Jordi Chancel, Assigned: mats)

Tracking

({crash, testcase, topcrash})

unspecified
mozilla2.0b8
crash, testcase, topcrash
Points:
---
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 .14-fixed, status1.9.1 unaffected)

Details

(Whiteboard: [sg:critical?], crash signature, URL)

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

7 years ago
Created attachment 489116 [details]
TESTCASE1
(Reporter)

Comment 2

7 years ago
Created attachment 489118 [details]
Screenshot [Access Violation]
(Assignee)

Comment 3

7 years ago
Created attachment 489126 [details]
stack 1.9.2 DEBUG on x86-64 Linux
(Assignee)

Comment 4

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

Comment 5

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

Comment 7

7 years ago
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.
Keywords: testcase-wanted
Mats, ping?
(Assignee)

Comment 12

6 years ago
Created attachment 494940 [details]
1.9.2 stack for failing EnsureCleanFrame
(Assignee)

Comment 13

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

Comment 14

6 years ago
Created attachment 494942 [details] [diff] [review]
trunk fix

I don't know this code at all, but I think this should at least avoid the crash.
Attachment #494942 - Flags: review?(bobbyholley+bmo)
(Assignee)

Comment 15

6 years ago
Created attachment 494943 [details] [diff] [review]
1.9.2 fix (same thing)
Attachment #494942 - Flags: review?(bobbyholley+bmo) → review?(joe)
(Assignee)

Comment 16

6 years ago
It passed TryServer unit tests, builds are here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mpalmgren@mozilla.com-d734b25e8af8/
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+
(Assignee)

Comment 18

6 years ago
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'
}
(Assignee)

Updated

6 years ago
Attachment #494942 - Flags: approval2.0?
(Assignee)

Updated

6 years ago
status1.9.1: --- → unaffected
status1.9.2: --- → ?
Ah, okay, so this was indeed an optimized image.
Attachment #494942 - Flags: approval2.0? → approval2.0+
(Assignee)

Comment 20

6 years ago
http://hg.mozilla.org/mozilla-central/rev/64e893aa5d95
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
(Assignee)

Updated

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

Comment 23

6 years ago
Filed follow up bug 617651.
(Assignee)

Comment 24

6 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/804203a74c60
status1.9.2: ? → .14-fixed
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?
(Reporter)

Comment 26

6 years ago
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.
(Reporter)

Comment 27

6 years ago
Created attachment 502194 [details]
ScreenShot2
Jordi, what build and OS were you running this? Was this a post-fix 1.9.2 nightly build?
(Reporter)

Comment 29

6 years ago
Tested on Windows Seven with Mozilla Firefox 3.6.13
Alias: CVE-2011-0061
(Reporter)

Comment 30

6 years ago
the update was for today? =>https://wiki.mozilla.org/Releases
(Assignee)

Comment 31

6 years ago
3.6.14 is delayed due to bug 633869.
(Reporter)

Comment 32

6 years ago
Have you an idea of the release date?
(Assignee)

Comment 33

6 years ago
Sorry, I don't know.
(Reporter)

Updated

6 years ago
Attachment #489118 - Attachment is obsolete: true
(Reporter)

Updated

6 years ago
Attachment #502194 - Attachment is obsolete: true
(Reporter)

Comment 34

6 years ago
Created attachment 513033 [details]
ScreenShot3
(Reporter)

Comment 35

6 years ago
the fix release is for today isn't it? :)
Yes.
(Assignee)

Comment 37

6 years ago
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+
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.