New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 258723 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Oct 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: JPEG info leak

Project Member Reported by lcamtuf@google.com, Jul 10 2013

Issue description

This page contains an alternating pattern of kitty.jpg (a legit hello kitty image) and 55.jpg, an image that is 'decoded' to what looks like uninitialized memory:

http://lcamtuf.coredump.cx/jpeg_leak/

It may take a couple of reloads, but you should eventually see one or more of the 55.jpg images decoding to a distorted 'hello kitty'.

At the bare minimum, this + <canvas> seems like a way to steal images across domains, although I suspect that the memory may contain non-image stuff, too.

This also affects Firefox, Safari, etc, by the looks of it.
 

Comment 1 by glider@chromium.org, Jul 10 2013

This bug is perfectly reproducible with Chrome on Linux. I couldn't reproduce it with google-chrome-asan (goto/chrome-asan) (because of the delayed reuse of the deallocated chunks), so this isn't a use-after-free.
Running 'ASAN_OPTIONS=malloc_fill_byte=b4 google-chrome-asan' causes the pictures in the right to become darkened, so this is really an uninit.

In all the cases Chrome prints the following line to the console:
Corrupt JPEG data: bad Huffman code
Owner: noel@chromium.org
Status: Assigned
Noel, can you please take a look or help with an owner.

Comment 3 by lcamtuf@google.com, Jul 10 2013

The file contains a SOS record for component 2 or 3, but not for component 1, which would be normally expected. A closer look at get_sos() in jdmarker.c is probably a good starting point?

Comment 4 by lcamtuf@google.com, Jul 10 2013

Yeah, I think it's that. We have Cr and Cb (chroma), but not Y (luma). The library doesn't notice that and applies chroma info over uninitialized memory?

Comment 5 by lcamtuf@google.com, Jul 10 2013

Large repro for your amusement:

http://lcamtuf.coredump.cx/jpeg_leak/random.jpg
Cc: taviso@google.com
[+taviso]

Tavis had something similar in Firefox? Tavis, I wonder if it's related?

Comment 7 by tav...@gmail.com, Jul 13 2013

Hmm, maybe, I don't think I ever looked into it. Mateusz says some of the images in my testsuite trigger the bug.

https://code.google.com/p/imagetestsuite/wiki/HtmlTestPage

Comment 8 by lcamtuf@google.com, Jul 13 2013

There is a longer discussion on ise-team@ if you're interested.

Comment 9 by lcamtuf@google.com, Jul 13 2013

There's also another one that seems to be specific to libjpeg-turbo, but I haven't investigated it at all and I don't know what causes it; I'll see if I can convince the maintainer to have a look:

http://lcamtuf.coredump.cx/jpeg_leak/182.jpg

For the original issue in this bug, we should probably come up with a fix, though.

Comment 10 by cdn@chromium.org, Jul 15 2013

Labels: -Pri-1 Pri-2 Security_Severity-Medium M-29 Security_Impact-Stable Security_Impact-Beta
Seems like a pretty awesome info leak :)

Comment 11 by noel@chromium.org, Jul 18 2013

#3 "The file contains a SOS record for component 2 or 3, but not for component 1, which would be normally expected. A closer look at get_sos() in jdmarker.c is probably a good starting point? "

Yes, the first component in SoS has id 3, instead of the expected 1.

% ./jpegcheck 55.jpg
Checking 55.jpg ...
Start of Image
JFIF APP0 marker: version 1.01, density 72x72  1
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=32, height=29, components=3
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
    Component 3: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Start Of Scan: 3 components
    Component 3: dc=0 ac=0     <-- Scan component 3 is wrong, it should be 1.
    Component 2: dc=1 ac=1
    Component 3: dc=1 ac=1
...




jpegcheck.c
2.8 KB View Download

Comment 12 by noel@chromium.org, Jul 18 2013

From http://www.w3.org/Graphics/JPEG/itu-t81.pdf, pp. 37, the SoS header

"SOS header CS[j] : Scan component selector - selects which of the Nf image components specified in the frame parameters shall be the j-th component in the scan ... The value of CS[j] shall be different from the values of CS[1] to CS[j – 1]."

The SOS header CS[j] (j = 1..3) in 55.jpeg are 3, 2, 3, the are not "different from" each other. The file is bogus according to the standard.


Comment 13 by noel@chromium.org, Jul 18 2013

*) Proposed Fix

Enforce the "CS[j] shall be different from" each other rule.  I've uploaded a patch to chrome's libjpeg_turbo to do just that by changing get_sos() to ...

 1 diff --git a/jdmarker.c b/jdmarker.c
 2 index 0d5da67..efc68c7 100644
 3 --- a/jdmarker.c
 4 +++ b/jdmarker.c
 5 @@ -303,7 +303,7 @@ get_sos (j_decompress_ptr cinfo)
 6  /* Process a SOS marker */
 7  {
 8    INT32 length;
 9 -  int i, ci, n, c, cc;
10 +  int i, ci, n, c, cc, pi;
11    jpeg_component_info * compptr;
12    INPUT_VARS(cinfo);
13
14 @@ -347,6 +347,12 @@ get_sos (j_decompress_ptr cinfo)
15
16      TRACEMS3(cinfo, 1, JTRC_SOS_COMPONENT, cc,
17              compptr->dc_tbl_no, compptr->ac_tbl_no);
18 +
19 +    /* This CSi (cc) should differ from the previous CSi */
20 +    for (pi = 0; pi < i; pi++) {
21 +      if (cinfo->cur_comp_info[pi] == compptr)
22 +        ERREXIT1(cinfo, JERR_BAD_COMPONENT_ID, cc);
23 +    }
24    }

https://codereview.appspot.com/11508043

With that fixed applied to desktop chrome, the test page draw broken image for me (good), picture attached.

jpeg-leak-fix.png
58.4 KB View Download

Comment 14 by lcamtuf@google.com, Jul 18 2013

Are we sure this is sufficient? In particular, what if I create a JPEG that has just two components in SOS (2 and 3)?

Comment 15 by noel@chromium.org, Jul 18 2013

> Are we sure this is sufficient?

I believe so for the 55.jpg case - give a whirl in a fuzzer?

> In particular, what if I create a JPEG that has just two components in SOS (2 and 3)?

Do you have such an image?

Comment 16 by lcamtuf@google.com, Jul 20 2013

For 55, I think that does it, but I'm not 100% sure it necessarily prevents images with a missing component 1 and no repetition. Based on a cursory grep, I don't have any fuzzer-generated testcases that toggle the condition and match this criteria, though. Maybe there is a check somewhere else in the code that prevents something like a two-component JPEG with just components 2 and 3.

I'll be OOO for three weeks, so just dumping all I have right now... in addition to 55.jpg, which affects libjpeg and libjpeg-turbo, I also have a separate but related issue that affects just turbo:

http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg

This one appears to have to do with the DHT marker. Here's the non-error-causing parent from which it's derived:

http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht-orig.jpg

PS. Just for your amusement, there's also one that affects just MSIE:

http://lcamtuf.coredump.cx/jpeg_leak/msie-uninit.jpg

@noel: will you be able to take care of http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg as part of this issue or should we file a new bug to track it? We don't want it to get lost.

Also, is there any way we can investigate Michal's question "In particular, what if I create a JPEG that has just two components in SOS (2 and 3)?" without relying on the fuzzer to create such an image (which it may never do?) I worry that we'll not investigate it, and get in to trouble if there's a real issue when this bug report becomes public ;-)

Comment 18 by noel@chromium.org, Jul 23 2013

> @noel: will you be able to take care of http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg as part of this issue or should we file a new bug to track it? We don't want it to get lost.

Checking turbo-dht.jpg
Start of Image
JFIF APP0 marker: version 1.01, density 72x72  1
Define Quantization Table 0  precision 0
Start Of Frame 0xc0: width=32, height=32, components=1
    Component 1: 1hx1v q=0
Define Huffman Table 0x00
Define Huffman Table 0x10
Start Of Scan: 1 components
    Component 1: dc=0 ac=0
  Ss=0, Se=63, Ah=0, Al=0
Starting decompressor ...
emit_message_warning
Corrupt JPEG data: bad Huffman code
...

Seems to be a separate bug, so a new issue for that would be good.


@noel: I think @lcamtuf is out for a few weeks without internet access. Would you like me to separate out the turbo-specific issue or would you like me to do it?

Comment 20 by noel@chromium.org, Jul 25 2013

#17 > but I'm not 100% sure it necessarily prevents images with a missing component 1 and no repetition. Based on a cursory grep, I don't have any fuzzer-generated testcases that toggle the condition and match this criteria, though. 
>Maybe there is a check somewhere else in the code that prevents something like a two-component JPEG with just components 2 and 3.

jdinput.c processing of the SOS header seems to allow two components in the initial SOS header of an image that has 3 or more components:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjpeg_turbo/jdinput.c&sq=package:chromium&type=cs&l=129&rcl=1374623590

  /* Decide whether file contains multiple scans */
  if (cinfo->comps_in_scan < cinfo->num_components || cinfo->progressive_mode)
    cinfo->inputctl->has_multiple_scans = TRUE;
  else
    cinfo->inputctl->has_multiple_scans = FALSE;

cinfo->comps_in_scan < cinfo == 2, cinfo->num_components == 3 implies cinfo->inputctl->has_multiple_scans == TRUE

We have no evidence that images with two SOS components could be used to create a information leak.








Comment 21 by noel@chromium.org, Jul 25 2013

Cc: mikelawther@chromium.org
#17 > Also, is there any way we can investigate Michal's question "In particular, what if I create a JPEG that has just two components in SOS (2 and 3)?" without relying on the fuzzer to create such an image (which it may never do?)

We spent some trying to manufacture 2 component images of various forms.

% jpegcheck start.jpg

Checking star.jpg ...
Start of Image
JFIF APP0 marker: version 1.01, density 1x1  0
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=179, height=169, components=2
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Start Of Scan: 2 components
    Component 1: dc=0 ac=0
    Component 2: dc=1 ac=1
  Ss=0, Se=63, Ah=0, Al=0
Starting decompressor ...
emit_warning ...
Corrupt JPEG data: bad Huffman code
error_exit ... Corrupt JPEG data: bad Huffman code
star.jpg BAD


star.jpg
4.3 KB View Download

Comment 22 by noel@chromium.org, Jul 25 2013

% jpegcheck strip-2comp-scan.jpg

Checking strip-2comp-scan.jpg ...
Start of Image
JFIF APP0 marker: version 1.01, density 1x1  0
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=259, height=194, components=3
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
    Component 3: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Start Of Scan: 2 components
    Component 2: dc=1 ac=1
    Component 3: dc=1 ac=1
  Ss=0, Se=63, Ah=0, Al=0
emit_warning ...
Corrupt JPEG data: bad Huffman code
error_exit ... Corrupt JPEG data: bad Huffman code
strip-2comp-scan.jpg BAD

strip-2comp-scan.jpg
9.7 KB View Download

Comment 23 by noel@chromium.org, Jul 25 2013

% jpegcheck strip-23-55.jpg

Checking strip-23-55.jpg ...
Start of Image
JFIF APP0 marker: version 1.01, density 72x72  1
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=32, height=29, components=3
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
    Component 3: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Start Of Scan: 2 components
    Component 2: dc=1 ac=1
    Component 3: dc=1 ac=1
  Ss=0, Se=63, Ah=0, Al=0
emit_warning ...
Corrupt JPEG data: bad Huffman code
error_exit ... Corrupt JPEG data: bad Huffman code
strip-23-55.jpg BAD

strip-23-55.jpg
640 bytes View Download

Comment 24 by noel@chromium.org, Jul 25 2013

% jpegcheck strip-12-55.jpg

Checking strip-12-55.jpg ...
Start of Image
JFIF APP0 marker: version 1.01, density 72x72  1
Define Quantization Table 0  precision 0
Define Quantization Table 1  precision 0
Start Of Frame 0xc0: width=32, height=29, components=3
    Component 1: 2hx2v q=0
    Component 2: 1hx1v q=1
    Component 3: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Start Of Scan: 2 components
    Component 3: dc=0 ac=0
    Component 2: dc=1 ac=1
  Ss=0, Se=63, Ah=0, Al=0
emit_warning ...
Corrupt JPEG data: bad Huffman code
error_exit ... Corrupt JPEG data: bad Huffman code
strip-12-55.jpg BAD

strip-12-55.jpg
640 bytes View Download

Comment 25 by noel@chromium.org, Jul 25 2013

Of these images, strip-2comp-scan.jpg is the only one that shows different paint on reload, like 55.jpg.  However, we've not been able to show that strip-2comp-scan.jpg can be used to create a leak.

Comment 26 by lcamtuf@google.com, Aug 19 2013

Cc: hasinoff@google.com
Hey,

Back from vacation. I also wasn't able to create a lower-component-count version, so I suspect that your fix for that should be good enough. Did we end up filing a separate bug for the libjpeg-turbo DHT issue somewhere?
Fix labels.
What work is left here ? Did some fix made in. Can you please add that info and close the bug.
Noel, this is an important info leak. Can you please priotize fixing this or helping with an owner.

Comment 30 by lcamtuf@google.com, Sep 20 2013

Hey,

We're getting close to three months on this bug, which is already past the 60-day deadline that we commit ourselves to.

I'd like to tentatively aim for releasing the test cases and the tool used to generate them somewhere around October 4, do you see any chance of having it resolved by then?

Comment 31 by aedla@chromium.org, Sep 26 2013

Cc: aedla@chromium.org
I took a large jpeg and changed the CCi for Y component from 1 to 3. Sure enough, Y component becomes filled with whatever is specified in malloc_fill_byte= indicating use of uninitialized memory. This seems to be happen because decompress_onepass() does:

    output_ptr = output_buf[compptr->component_index]

Here component_index = 2, where it would normally be 0. So nothing is ever written to component 0.


But also in the bottom two thirds of the image, U and V components change randomly with each reload. So this was weird because I specified malloc_fill_byte= and there was no use after free. Where would the randomness come from? I traced the random bits to uninitialized stack memory from get_dht() :

  UINT8 huffval[256];

  ...

  count = 0;
  for (i = 1; i <= 16; i++) {
    INPUT_BYTE(cinfo, bits[i], return FALSE);
    count += bits[i];
  }

  ...

  for (i = 0; i < count; i++)
    INPUT_BYTE(cinfo, huffval[i], return FALSE)

  ...

  MEMCOPY((*htblptr)->huffval, huffval, SIZEOF((*htblptr)->huffval));

So this can copy uninitialized stack memory into (*htblptr)->huffval. I suspect that the uninitialized memory can also be used without messing with CCi values, but I'm not sure. In any case, I think we should memset huffval to NULs.
esopia.jpg
172 KB View Download

Comment 32 by jww@chromium.org, Sep 27 2013

Labels: Cr-Blink-Canvas

Comment 33 by aedla@chromium.org, Sep 27 2013

huffval infoleak is definitely a different issue from the missing Y component issue. Attached is a reproducer for huffval infoleak, that doesn't change CCi, but instead contains a large invalid huffman code. To make the use of uninitialized memory more clear, apply huffval_infoleak.patch, that forces the leaked bytes to change randomly.

This only impacts libjpeg_turbo, not libjpeg which has a check:

  if (l > 16) {
    WARNMS(state->cinfo, JWRN_HUFF_BAD_CODE);
    return 0;                   /* fake a zero as the safest result */
  }

The reason this issue came out in the first place is that changing CCi of Y component from 1 to 3 makes Y component use a huffman table of U and V components.
huffval_infoleak.jpg
172 KB View Download
huffval_infoleak.patch
1.0 KB View Download

Comment 34 by aedla@chromium.org, Sep 27 2013

Cc: lcamtuf@google.com
Oh, now I notice lcamtuf's turbo-dht.jpg, which is probably the same huffval issue :) Will take a closer look...

Comment 35 by aedla@chromium.org, Sep 27 2013

Sure enough, turbo-dht.jpg does a bunch of bad accesses on huffval:

huffval[0xc8] = 0xd0
huffval[0x6c] = 0x00
huffval[0x8d] = 0x60
huffval[0xa9] = 0x3e
huffval[0x28] = 0x3f

Past 0x12 bytes, huffval contains garbage. Initializing all of huffval to NULs stops turbo-dht.jpg from changing randomly.

Comment 36 by aedla@chromium.org, Sep 27 2013

Separated turbo DHT bug into  issue 299835 .
Project Member

Comment 37 by ClusterFuzz, Sep 27 2013

Labels: Nag
noel@: you haven't provided any bug update or come up with a fix for this issue in the last 7 days. Please note that this is a medium+ severity security vulnerability that needs your immediate response. If you have a patch in progress and don't want future nags, please add a codereview link and a WIP label. If the issue is already fixed or you can't reproduce it, please close the bug.

Comment 38 by aedla@chromium.org, Sep 28 2013

I looked at the possibility of creating images with less than 3 components to leak memory. Like noel and lcamtuf, I couldn't do it.

According to my code reading, setting num_components = 1 causes the input to be grayscale, which is converted to RGB. Setting num_components = 2 errors out. Setting comps_in_scan < num_components causes a buffer to be allocated for the whole image with num_components components. This buffer is zeroed out.
Project Member

Comment 39 by ClusterFuzz, Oct 1 2013

Labels: -M-29 M-30
Fixing milestone and impact labels.
Project Member

Comment 40 by ClusterFuzz, Oct 6 2013

noel@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!)

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Project Member

Comment 41 by ClusterFuzz, Oct 6 2013

noel@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!)

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Project Member

Comment 42 by ClusterFuzz, Oct 6 2013

noel@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!)

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Sorry for the multiple nag comments in the last 24 hrs. It was supposed to be just one per week :), but a bug in sheriffbot caused it to generate multiple ones. Sorry for the inconvenience.
Project Member

Comment 44 by bugdroid1@chromium.org, Oct 12 2013

------------------------------------------------------------------------
r228354 | noel@chromium.org | 2013-10-12T17:21:44.485733Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker.c?r1=228354&r2=228353&pathrev=228354
   A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/google.jdmarker.patch?r1=228354&r2=228353&pathrev=228354
   M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/README.chromium?r1=228354&r2=228353&pathrev=228354

Better handle SOS CSi values and order

Image SOS CSi markers should be distinct. Enforce that constraint when
reading multiple CSi values in get_sos().

TBR=darin@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/27008002
------------------------------------------------------------------------
Project Member

Comment 45 by bugdroid1@chromium.org, Oct 13 2013

------------------------------------------------------------------------
r228381 | noel@chromium.org | 2013-10-13T00:51:52.301921Z

Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/google.jdmarker.patch?r1=228381&r2=228380&pathrev=228381
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/README.chromium?r1=228381&r2=228380&pathrev=228381
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmarker.c?r1=228381&r2=228380&pathrev=228381

Better handle SOS CSi values and order

Image SOS CSi markers should be distinct. Enforce that constraint when
reading multiple CSi values in get_sos().

TBR=darin@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/27117002
------------------------------------------------------------------------

Comment 46 by noel@chromium.org, Oct 13 2013

@#9 the image 182.jpg shows reload behavior, not due to this bug. Moving it on to  issue 299835 .

Comment 47 by noel@chromium.org, Oct 13 2013

Similarly for strip-2comp-scan.jpg image from #22, move them on to  issue 299835 .

Comment 48 by noel@chromium.org, Oct 13 2013

Similarly strip-12-55.jpg from #24 shows reload behavior on Chrome 32 dev.  Moving it on to  issue 299835 .

Comment 49 by noel@chromium.org, Oct 13 2013

Moved strip-23-55.jpg from #23 on to  issue 299835 .

Comment 50 by noel@chromium.org, Oct 13 2013

The bug here is missing component bug.  Searching around; the fact that missing components cause issues for jpeg decodes has was discussed in public circa 2003

  Bug report: stripes in pdf
  http://bugs.ghostscript.com/show_bug.cgi?id=686980

  [gs-code-review] Proposed patch to libjpeg to workaround comp id [686980]
  http://ghostscript.com/pipermail/gs-code-review/2004-June/004579.html

  libjpeg6b interprets the id, and creates garbage output when they're invalid
  http://ghostscript.com/pipermail/gs-cvs/2005-March/005363.html

Comment 51 by noel@chromium.org, Oct 13 2013

Regarding the info leak: teh repro http://lcamtuf.coredump.cx/jpeg_leak has images in pairs: kitty2.jpg on the left, and 55.jpg on the right.

If I assign component = 1 for every component in 55.jpg, a kitty-like images results when loaded in both chrome and Firefox (attached 1-channel-55.jpg, and a chrome 30 stable win32 creen shot).





1-channel-55.jpg
642 bytes View Download
1-channel-55-screen-shot.png
19.7 KB View Download

Comment 52 by lcamtuf@google.com, Oct 13 2013

Yeah, that's the original Hello Kitty image used to generate 55.jpg (don't ask why)

Comment 53 by noel@chromium.org, Oct 13 2013

It seems kitty2.jpg and 55.jpg contain related data, and that'd be enough to explain the "leak".  A more convincing "leak" test would not use kitty2.jpg; it would use an unrelated image of the same size.


Comment 54 by lcamtuf@google.com, Oct 13 2013

Related how? They're Hello Kitty images, but they are completely different otherwise...

Comment 55 by lcamtuf@google.com, Oct 13 2013

I mean, if it seriously can't be two cats, here's a fox and a grumpy cat:

http://lcamtuf.coredump.cx/jpeg_leak2/

Comment 56 by noel@chromium.org, Oct 13 2013

Here's a circular shape (57.jpg) in a test case (55.html) against 55.jpg.  The circular shape leaks in Chrome-mac, Firefox-mac, and Safari for me.

With the patch #45 in chrome-mac, there's no leak.

55.html
3.0 KB View Download
57.jpg
949 bytes View Download
Project Member

Comment 57 by bugdroid1@chromium.org, Oct 13 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=159532

------------------------------------------------------------------------
r159532 | noel@chromium.org | 2013-10-13T12:33:59.405251Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/images/resources/55.jpg?r1=159532&r2=159531&pathrev=159532
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/images/resources/57.jpg?r1=159532&r2=159531&pathrev=159532

Add more jpeg test image resources

TBR=mikelawther@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/26580004
------------------------------------------------------------------------
Project Member

Comment 58 by bugdroid1@chromium.org, Oct 13 2013

------------------------------------------------------------------------
r228399 | noel@chromium.org | 2013-10-13T18:11:42.615592Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=228399&r2=228398&pathrev=228399

Update libjpeg_turbo to HEAD

TBR=inferno
BUG= 258723 

Review URL: https://codereview.chromium.org/27102003
------------------------------------------------------------------------
Labels: -Restrict-View-SecurityTeam -Nag Restrict-View-SecurityNotify M-31 Merge-Requested
Status: Fixed
Project Member

Comment 61 by bugdroid1@chromium.org, Oct 14 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=159566

------------------------------------------------------------------------
r159566 | ojan@chromium.org | 2013-10-14T08:14:21.395221Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac/virtual/deferred/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac-snowleopard/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/win/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/virtual/deferred/fast/images/55-expected.txt?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/linux/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac-lion/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac-snowleopard/virtual/deferred/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/win/virtual/deferred/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/TestExpectations?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/linux/virtual/deferred/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac-lion/virtual/deferred/fast/images/55-expected.png?r1=159566&r2=159565&pathrev=159566

Auto-rebaseline for r159561

http://src.chromium.org/viewvc/blink?view=revision&revision=159561

BUG= 258723 
TBR=noel@chromium.org

Review URL: https://codereview.chromium.org/27163002
------------------------------------------------------------------------

Comment 62 by cdn@chromium.org, Oct 16 2013

Cc: ukbe...@gmail.com
CCing David Belcher from Rim

Comment 63 by laforge@google.com, Oct 18 2013

Labels: -Merge-Requested Merge-Approved
Approved for 31.
Labels: Release-0-M31
Project Member

Comment 65 by bugdroid1@chromium.org, Oct 21 2013

Labels: -Merge-Approved merge-merged-1599
------------------------------------------------------------------------
r229729 | noel@chromium.org | 2013-10-21T03:45:14.738603Z

Changed paths:
   A http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/google.jdmarker.patch?r1=229729&r2=229728&pathrev=229729
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/README.chromium?r1=229729&r2=229728&pathrev=229729
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/jdmarker.c?r1=229729&r2=229728&pathrev=229729

Merge 228354 "Better handle SOS CSi values and order"

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/31603002
------------------------------------------------------------------------
Project Member

Comment 66 by bugdroid1@chromium.org, Oct 21 2013

------------------------------------------------------------------------
r229731 | noel@chromium.org | 2013-10-21T03:53:42.978970Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/DEPS?r1=229731&r2=229730&pathrev=229731

Merge 228399 "Update libjpeg_turbo to HEAD"

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/31423003
------------------------------------------------------------------------
we wont have any more m30s patches, this is merge-approved for m31. m31 is branch 1650.
The mail that noel got from laforge said to merge to branch 1599, which is what we did.
Project Member

Comment 69 by bugdroid1@chromium.org, Oct 21 2013

------------------------------------------------------------------------
r229746 | noel@chromium.org | 2013-10-21T06:40:06.525953Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/DEPS?r1=229746&r2=229745&pathrev=229746

Revert 229731 "Merge 228399 "Update libjpeg_turbo to HEAD""

> Merge 228399 "Update libjpeg_turbo to HEAD"
> 
> TBR=noel@chromium.org
> BUG= 258723 
> 
> Review URL: https://codereview.chromium.org/31423003

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/31863002
------------------------------------------------------------------------
Project Member

Comment 70 by bugdroid1@chromium.org, Oct 21 2013

------------------------------------------------------------------------
r229747 | noel@chromium.org | 2013-10-21T06:42:37.402438Z

Changed paths:
   D http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/google.jdmarker.patch?r1=229747&r2=229746&pathrev=229747
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/README.chromium?r1=229747&r2=229746&pathrev=229747
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/third_party/libjpeg/jdmarker.c?r1=229747&r2=229746&pathrev=229747

Revert 229729 "Merge 228354 "Better handle SOS CSi values and or..."

> Merge 228354 "Better handle SOS CSi values and order"
> 
> TBR=noel@chromium.org
> BUG= 258723 
> 
> Review URL: https://codereview.chromium.org/31603002

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/31873002
------------------------------------------------------------------------

Comment 71 by noel@chromium.org, Oct 21 2013

Backed out of 1599, resubmitting to 1650 ...

Project Member

Comment 72 by bugdroid1@chromium.org, Oct 21 2013

Labels: merge-merged-1650
------------------------------------------------------------------------
r229748 | noel@chromium.org | 2013-10-21T06:49:29.754522Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1650/src/third_party/libjpeg/README.chromium?r1=229748&r2=229747&pathrev=229748
   M http://src.chromium.org/viewvc/chrome/branches/1650/src/third_party/libjpeg/jdmarker.c?r1=229748&r2=229747&pathrev=229748
   A http://src.chromium.org/viewvc/chrome/branches/1650/src/third_party/libjpeg/google.jdmarker.patch?r1=229748&r2=229747&pathrev=229748

Merge 228354 "Better handle SOS CSi values and order"

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/28763005
------------------------------------------------------------------------
Project Member

Comment 73 by bugdroid1@chromium.org, Oct 21 2013

------------------------------------------------------------------------
r229749 | noel@chromium.org | 2013-10-21T06:51:30.990362Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1650/src/DEPS?r1=229749&r2=229748&pathrev=229749

Merge 228399 "Update libjpeg_turbo to HEAD"

TBR=noel@chromium.org
BUG= 258723 

Review URL: https://codereview.chromium.org/31893002
------------------------------------------------------------------------
Labels: -merge-merged-1599
Noel, you rock!
Project Member

Comment 75 by bugdroid1@chromium.org, Oct 25 2013

The following revision refers to this bug:
    http://goto.ext.google.com/viewvc/chrome-internal?view=rev&revision=43670

------------------------------------------------------------------------
r43670 | cevans@google.com | 2013-10-25T18:34:26.259534Z

------------------------------------------------------------------------
Labels: -M-30
Merging DEPS files is tricky.
I updated src-branch/DEPS (r43670) for the latest libjpeg_turbo revision on M31 branch. Now, the changes are visible on an M31 branch build.
Cc: dved...@gmail.com
Labels: CVE-2013-6629
Cc: sgu...@chromium.org joth@chromium.org
Cc: -sgu...@chromium.org -joth@chromium.org
Project Member

Comment 81 by ClusterFuzz, Feb 6 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 82 by bugdroid1@chromium.org, Apr 14 2014

------------------------------------------------------------------
r263594 | noel@chromium.org | 2014-04-14T06:56:00.594957Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jquant1.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmrgext.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jquant2.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jdmrgss2.asm?r1=263594&r2=263593&pathrev=263594
   D http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/google.jdmarker.patch?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jcmainct.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmainct.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jccolor.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jcdctmgr.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jddctmgr.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdatadst.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/README.chromium?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/turbojpeg.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jchuff.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/turbojpeg.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdatasrc-tj.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdhuff.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jcmaster.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdatadst-tj.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmaster.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/config.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jccolext.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdhuff.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/transupp.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdcolext.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/tjbench.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmerge.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdinput.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/tjunittest.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/bmp.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/turbojpeg-jni.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jdclrss2.asm?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jpeglib.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/transupp.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/bmp.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/README-turbo.txt?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/ChangeLog.txt?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jconfig.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/change.log?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdphuff.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/rdswitch.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/cjpeg.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/djpeg.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdatasrc.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdcolor.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jcmarker.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdmarker.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdsample.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jsimd_arm_neon.S?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jmorecfg.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jsimd_arm.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdapistd.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/rdbmp.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jversion.h?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jdclrss2-64.asm?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jpegtran.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/README?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/simd/jdmrgss2-64.asm?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jcparam.c?r1=263594&r2=263593&pathrev=263594
   M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/jdcoefct.c?r1=263594&r2=263593&pathrev=263594

Upgrade libjpeg_turbo to 1.3.1 (r1219)

Remove google.jdmarker.patch, since the fixes for CVE-2013-6629
and CVE-2013-6630 are upstream most everywhere now [1]. Version
number to 1.3.1 (config.h, jconfig.h).

README.chromium: "Fixed valgrind error" patch was upstreamed in
r839 http://sourceforge.net/p/libjpeg-turbo/code/839. The r1188
cherry-pick was put in config.h, say that.

[1] http://seclists.org/fulldisclosure/2013/Nov/83

TBR=darin@chromium.org
BUG= 258723 ,  299835 

Review URL: https://codereview.appspot.com/87110044
-----------------------------------------------------------------

Comment 83 by noel@chromium.org, May 3 2014

Status: Verified
Project Member

Comment 84 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 85 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 86 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment