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

Issue 653867 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue webp:312
Owner:
Closed: Oct 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: libwebp heap overflow

Reported by cnevilm...@gmail.com, Oct 7 2016

Issue description

Hi.

I already opened an issue on webp project. But the status isn't 
updated yet. The url is as follow.

https://bugs.chromium.org/p/webp/issues/detail?id=312

I'm not sure which project i should submit.

This is PeiwenChen(@EvilM00n) of Tencent's Xuanwu Lab.

During my research, I found a heap overflow vulnerability in cwebp.
When cwebp is converting jpeg format to webp format,it will pass 
image's "num_rows" value into libjpeg . This can directly cause 
a heap overflow vulnerability.


The vulnerability appears in cwebp 0.5.1 and libjpeg9b(Independent 
JPEG Group's CJPEG, version 9b  17-Jan-2016) .But it also appears 
in other versions of libpeg.

Attached is a proof of concept and backtrace and ASAN output.

Regards,
Peiwen Chen
Tencent's Xuanwu Lab


gdb-peda$ r poc -o 1.webp
Starting program: /usr/local/bin/cwebp poc -o 1.webp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Corrupt JPEG data: 2 extraneous bytes before marker 0xda

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0x7ffff6ff4000 --> 0x10102464c457f 
RBX: 0x7ffff6ff3fff --> 0x10102464c457f00 
RCX: 0x80 
RDX: 0x7ffff6ff4001 --> 0x10102464c45 
RSI: 0x60e058 --> 0x60e5d0 --> 0x7ffff7fbb248 --> 0x8080808080808080 
RDI: 0x7fffffffe1b0 --> 0x7fffffffe040 --> 0x40729e (<my_error_exit>:	push   rbp)
RBP: 0x7fffffffdea0 --> 0x7fffffffdf00 --> 0x7fffffffdf50 --> 0x7fffffffdf90 --> 0x7fffffffe460 --> 0x7fffffffe4b0 --> 0x7fffffffe9a0 --> 0x0 
RSP: 0x7fffffffde88 --> 0x0 
RIP: 0x7ffff78f72bc (<gray_rgb_convert+111>:	mov    BYTE PTR [rdx],cl)
R8 : 0x1 
R9 : 0x7fffffffdf8c --> 0xffffe46000000000 
R10: 0x60e58c --> 0x4 
R11: 0x7ffff78f23e0 (<jpeg_read_scanlines>:	push   rbp)
R12: 0x3499 
R13: 0x7ffff7fbb248 --> 0x8080808080808080 
R14: 0x0 
R15: 0x0
[-------------------------------------code-------------------------------------]
   0x7ffff78f72b3 <gray_rgb_convert+102>:	mov    ecx,r12d
   0x7ffff78f72b6 <gray_rgb_convert+105>:	add    rcx,r13
   0x7ffff78f72b9 <gray_rgb_convert+108>:	movzx  ecx,BYTE PTR [rcx]
=> 0x7ffff78f72bc <gray_rgb_convert+111>:	mov    BYTE PTR [rdx],cl
   0x7ffff78f72be <gray_rgb_convert+113>:	movzx  edx,BYTE PTR [rdx]
   0x7ffff78f72c1 <gray_rgb_convert+116>:	mov    BYTE PTR [rax],dl
   0x7ffff78f72c3 <gray_rgb_convert+118>:	movzx  eax,BYTE PTR [rax]
   0x7ffff78f72c6 <gray_rgb_convert+121>:	mov    BYTE PTR [rbx],al
[------------------------------------stack-------------------------------------]
00:0000| rsp 0x7fffffffde88 --> 0x0 
01:0008|     0x7fffffffde90 --> 0x401c00 (<_start>:	xor    ebp,ebp)
02:0016|     0x7fffffffde98 --> 0x7fffffffea80 --> 0x4 
03:0024| rbp 0x7fffffffdea0 --> 0x7fffffffdf00 --> 0x7fffffffdf50 --> 0x7fffffffdf90 --> 0x7fffffffe460 --> 0x7fffffffe4b0 --> 0x7fffffffe9a0 --> 0x0 
04:0032|     0x7fffffffdea8 --> 0x7ffff7904d53 (<sep_upsample+403>:	mov    rax,QWORD PTR [rbp-0x50])
05:0040|     0x7fffffffdeb0 --> 0x7fffffffdf8c --> 0xffffe46000000000 
06:0048|     0x7fffffffdeb8 --> 0x7fffffffdfe0 --> 0x7ffff6fea234 --> 0x8080808080808080 
07:0056|     0x7fffffffdec0 --> 0x800000001 
[------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
Stopped reason: SIGSEGV
0x00007ffff78f72bc in gray_rgb_convert (cinfo=0x7fffffffe1b0, input_buf=0x60e058, input_row=0x1, output_buf=0x7fffffffdfe8, num_rows=0x0) at jdcolor.c:493
493	      outptr[RGB_RED] = outptr[RGB_GREEN] = outptr[RGB_BLUE] = inptr[col];
gdb-peda$ bt
#0  0x00007ffff78f72bc in gray_rgb_convert (cinfo=0x7fffffffe1b0, input_buf=0x60e058, input_row=0x1, output_buf=0x7fffffffdfe8, num_rows=0x0) at jdcolor.c:493
#1  0x00007ffff7904d53 in sep_upsample (cinfo=0x7fffffffe1b0, input_buf=0x60e538, in_row_group_ctr=0x60e58c, in_row_groups_avail=0x8, output_buf=0x7fffffffdfe0, out_row_ctr=0x7fffffffdf8c, out_rows_avail=0x1) at jdsample.c:129
#2  0x00007ffff78fdad7 in process_data_simple_main (cinfo=0x7fffffffe1b0, output_buf=0x7fffffffdfe0, out_row_ctr=0x7fffffffdf8c, out_rows_avail=0x1) at jdmainct.c:368
#3  0x00007ffff78f24f4 in jpeg_read_scanlines (cinfo=0x7fffffffe1b0, scanlines=0x7fffffffdfe0, max_lines=0x1) at jdapistd.c:174
#4  0x0000000000407653 in ReadJPEG (data=0x60d250 "\377\330\377", <incomplete sequence \340>, data_size=0x94, pic=0x7fffffffe790, keep_alpha=0x1, metadata=0x0) at jpegdec.c:308
#5  0x000000000040205c in ReadPicture (filename=0x7fffffffecfb "poc", pic=0x7fffffffe790, keep_alpha=0x1, metadata=0x0) at cwebp.c:110
#6  0x0000000000405a06 in main (argc=0x4, argv=0x7fffffffea88) at cwebp.c:953
#7  0x00007ffff731bf45 in __libc_start_main (main=0x403b5c <main>, argc=0x4, argv=0x7fffffffea88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffea78) at libc-start.c:287
#8  0x0000000000401c29 in _start ()



$ cwebp poc  -o 1.webp
Corrupt JPEG data: 2 extraneous bytes before marker 0xda
=================================================================
==15220== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f2fb9a55407 at pc 0x7f2fba7aa6a7 bp 0x7ffd5f2c3bc0 sp 0x7ffd5f2c3bb8
WRITE of size 1 at 0x7f2fb9a55407 thread T0
    #0 0x7f2fba7aa6a6 (/usr/local/lib/libjpeg.so.9.2.0+0x516a6)
    #1 0x7f2fba7da97d (/usr/local/lib/libjpeg.so.9.2.0+0x8197d)
    #2 0x7f2fba7c101b (/usr/local/lib/libjpeg.so.9.2.0+0x6801b)
    #3 0x7f2fba79a981 (/usr/local/lib/libjpeg.so.9.2.0+0x41981)
    #4 0x40d64b (/usr/local/bin/cwebp+0x40d64b)
    #5 0x4028ee (/usr/local/bin/cwebp+0x4028ee)
    #6 0x409928 (/usr/local/bin/cwebp+0x409928)
    #7 0x7f2fba197f44 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21f44)
    #8 0x401f68 (/usr/local/bin/cwebp+0x401f68)
0x7f2fb9a55407 is located 1 bytes to the right of 1813510-byte region [0x7f2fb989a800,0x7f2fb9a55406)
allocated by thread T0 here:
    #0 0x7f2fbad8b41a (/usr/lib/x86_64-linux-gnu/libasan.so.0.0.0+0x1541a)
    #1 0x40d5e1 (/usr/local/bin/cwebp+0x40d5e1)
    #2 0x4028ee (/usr/local/bin/cwebp+0x4028ee)
    #3 0x409928 (/usr/local/bin/cwebp+0x409928)
    #4 0x7f2fba197f44 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21f44)
Shadow bytes around the buggy address:
  0x0fe677342a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe677342a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe677342a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe677342a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe677342a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe677342a80:[06]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe677342a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe677342aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe677342ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe677342ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe677342ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==15220== ABORTING



 
2016-10-01-webp-poc.jpg
148 bytes View Download
Cc: fbarchard@chromium.org
Owner: jzern@chromium.org
Status: ExternalDependency (was: Unconfirmed)
Marking as an upstream issue, but adding a couple of people who overlap both worlds.

Comment 2 by jzern@chromium.org, Oct 7 2016

Mergedinto: webp:312
Status: Duplicate (was: ExternalDependency)
Thanks for the ping. I updated the template on the webp side to force an owner, otherwise these can be easily missed as shown.
I'm marking this one as a duplicate of the upstream bug, as it deals with the example code and from a quick look seems like the problem is in libjpeg itself which libwebp maintainers don't control. The attached file doesn't cause any issue with chrome 53.0.2785.143.
Project Member

Comment 3 by sheriffbot@chromium.org, Jan 14 2017

Labels: -Restrict-View-SecurityTeam allpublic
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

Sign in to add a comment