Issue metadata
Sign in to add a comment
|
Security: libwebp heap overflow
Reported by
cnevilm...@gmail.com,
Oct 7 2016
|
||||||||||||||||||||||
Issue descriptionHi. 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
,
Oct 7 2016
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.
,
Jan 14 2017
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 |
|||||||||||||||||||||||
Comment 1 by tsepez@chromium.org
, Oct 7 2016Owner: jzern@chromium.org
Status: ExternalDependency (was: Unconfirmed)