Issue metadata
Sign in to add a comment
|
Security: PDFium: Heap Buffer Overflow in libtiff's TIFFFetchStripThing Function
Reported by
stackexp...@gmail.com,
Jun 10 2016
|
||||||||||||||||||||
Issue description
Security: PDFium: Heap Buffer Overflow in libtiff's TIFFFetchStripThing Function
VULNERABILITY DETAILS
This heap-buffer-overflow vulnerability was caused by the malformed tiff image embedded in the PDF document. More specifically, this issue can be triggered by embedding a malformed tiff image in the XFA component.
The latest beta version of Chrome was vulnerable to this issue.
----------------------------
AddressSanitizer Information
----------------------------
==2559==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb1607d40 at pc 0x080fad74 bp 0xbfa4f4f8 sp 0xbfa4f0d8
WRITE of size 264 at 0xb1607d40 thread T0
#0 0x80fad73 in __asan_memcpy (out/Release/pdfium_test+0x80fad73)
#1 0xc90663f in _TIFFmemcpy out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:75:3
#2 0xc974b87 in TIFFFetchStripThing out/Release/../../third_party/libtiff/tif_dirread.c:5392:4
#3 0xc957689 in TIFFReadDirectory out/Release/../../third_party/libtiff/tif_dirread.c:3722:10
#4 0xc9abb0a in TIFFClientOpen out/Release/../../third_party/libtiff/tif_open.c:466:8
#5 0xc90be74 in (anonymous namespace)::tiff_open(void*, char const*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:138:15
#6 0xc90be74 in CCodec_TiffContext::InitDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:194
#7 0xc90be74 in CCodec_TiffModule::CreateDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:436
#8 0xc8f70d8 in CCodec_ProgressiveDecoder::DetectImageType(FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1261:24
#9 0xc8f935c in CCodec_ProgressiveDecoder::LoadImageInfo(IFX_FileRead*, FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1319:9
#10 0xbf3f1bd in XFA_LoadImageFromBuffer(IFX_FileRead*, FXCODEC_IMAGE_TYPE, int&, int&) out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1072:3
#11 0xbf3ea77 in XFA_LoadImageData(CXFA_FFDoc*, CXFA_Image*, int&, int&, int&) out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1031:7
#12 0xbf50d88 in CXFA_ImageLayoutData::LoadImageData(CXFA_WidgetAcc*) out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:96:25
#13 0xbf4ec7d in CXFA_WidgetAcc::LoadImageImage() out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:1001:45
#14 0xc3827d5 in CXFA_FFImage::LoadWidget() out/Release/../../xfa/fxfa/app/xfa_ffimage.cpp:27:3
#15 0xbf0c50c in CXFA_FFPageWidgetIterator::GetWidget(CXFA_LayoutItem*) out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:192:7
#16 0xbf0cfa0 in CXFA_FFPageWidgetIterator::MoveToNext() out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:162:34
#17 0x81b12ef in CPDFSDK_PageView::LoadFXAnnots() out/Release/../../fpdfsdk/fsdk_mgr.cpp:927:39
#18 0x81b05cc in CPDFSDK_Document::GetPageView(CPDFXFA_Page*, int) out/Release/../../fpdfsdk/fsdk_mgr.cpp:274:3
#19 0x815281c in (anonymous namespace)::FormHandleToPageView(void*, void*) out/Release/../../fpdfsdk/fpdfformfill.cpp:45:20
#20 0x815281c in FORM_OnAfterLoadPage out/Release/../../fpdfsdk/fpdfformfill.cpp:642
#21 0x813eb7c in RenderPage(std::string const&, void* const&, void* const&, int, Options const&, std::string const&) out/Release/../../samples/pdfium_test.cc:497:3
#22 0x8140ceb in RenderPdf(std::string const&, char const*, unsigned int, Options const&, std::string const&) out/Release/../../samples/pdfium_test.cc:694:9
#23 0x8142d03 in main out/Release/../../samples/pdfium_test.cc:835:5
#24 0xb73d7a82 in __libc_start_main /build/eglibc-617sU_/eglibc-2.19/csu/libc-start.c:287
#25 0x807e5c3 in _start (out/Release/pdfium_test+0x807e5c3)
0xb1607d40 is located 0 bytes to the right of 64-byte region [0xb1607d00,0xb1607d40)
allocated by thread T0 here:
#0 0x8116609 in realloc (out/Release/pdfium_test+0x8116609)
#1 0xc90659e in _TIFFrealloc out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:67:10
#2 0xc957689 in TIFFReadDirectory out/Release/../../third_party/libtiff/tif_dirread.c:3722:10
#3 0xc9abb0a in TIFFClientOpen out/Release/../../third_party/libtiff/tif_open.c:466:8
#4 0xc90be74 in (anonymous namespace)::tiff_open(void*, char const*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:138:15
#5 0xc90be74 in CCodec_TiffContext::InitDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:194
#6 0xc90be74 in CCodec_TiffModule::CreateDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:436
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 __asan_memcpy
Shadow bytes around the buggy address:
0x362c0f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362c0f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362c0f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362c0f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x362c0f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x362c0fa0: 00 00 00 00 00 00 00 00[fa]fa fa fa 00 00 00 00
0x362c0fb0: 00 00 00 00 fa fa fa fa fd fd fd fd fd fd fd fa
0x362c0fc0: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
0x362c0fd0: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd
0x362c0fe0: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd
0x362c0ff0: fa fa fa fa fd fd fd fd fd fd fd fd 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 right 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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==2559==ABORTING
---------------------------
Source Code Information
---------------------------
5365 /*
5366 * Fetch a set of offsets or lengths.
5367 * While this routine says "strips", in fact it's also used for tiles.
5368 */
5369 static int
5370 TIFFFetchStripThing(TIFF* tif, TIFFDirEntry* dir, uint32 nstrips, uint64** lpp)
5371 {
5372 static const char module[] = "TIFFFetchStripThing";
5373 enum TIFFReadDirEntryErr err;
5374 uint64* data;
5375 err=TIFFReadDirEntryLong8Array(tif,dir,&data);
5376 if (err!=TIFFReadDirEntryErrOk)
5377 {
5378 const TIFFField* fip = TIFFFieldWithTag(tif,dir->tdir_tag);
5379 TIFFReadDirEntryOutputErr(tif,err,module,fip ? fip->field_name : "unknown tagname",0);
5380 return(0);
5381 }
5382 if (dir->tdir_count!=(uint64)nstrips)
5383 {
5384 uint64* resizeddata;
5385 resizeddata=(uint64*)_TIFFCheckMalloc(tif,nstrips,sizeof(uint64),"for strip array");
5386 if (resizeddata==0) {
5387 _TIFFfree(data);
5388 return(0);
5389 }
5390 if (dir->tdir_count<(uint64)nstrips)
5391 {
5392 _TIFFmemcpy(resizeddata,data,(uint32)dir->tdir_count*sizeof(uint64)); // <----------------------------- Heap Buffer Overflow!!!
5393 _TIFFmemset(resizeddata+(uint32)dir->tdir_count,0,(nstrips-(uint32)dir->tdir_count)*sizeof(uint64));
5394 }
5395 else
5396 _TIFFmemcpy(resizeddata,data,nstrips*sizeof(uint64));
5397 _TIFFfree(data);
5398 data=resizeddata;
5399 }
5400 *lpp=data;
5401 return(1);
5402 }
---------------------------
PoC Diff
---------------------------
The root cause of this issue was not clearly. There were too many changes, I'm not sure what's going on.
VERSION
Chrome Version: [Beta]
Operating System: [Ubuntu 14.04]
REPRODUCTION CASE
Both the malformed tiff file and the proof-of-concept PDF file were attached.
FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab]
,
Jun 10 2016
,
Jun 10 2016
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6606219095834624
,
Jun 10 2016
XFA is currently disabled, per http://crbug.com/618164#c20
,
Jun 12 2016
Please do not close this issue for now. I think it's irresponsible to close this issue directly before we come to an agreement. Please give your reason if you think it's not a security bug. ClusterFuzz cannot reproduce the crash because you have disabled XFA for both chrome and pdfium. I think you have already disabled XFA in pdfium. I've tested pdfium_test.exe in the ASAN package (https://www.googleapis.com/download/storage/v1/b/chromium-browser-asan/o/win32-release%2Fasan-win32-release-399234.zip?generation=1465597814368000&alt=media) and found that XFA was disabled. So it's not strange that ClusterFuzz can't repro using the attached pdf. This issue still can be reproduced on the old version of pdfium_test taken from your ASAN package. Here is my testing environment. OS: Ubuntu 14.04 32Bit Compiler: Clang / Clang++ AddressSanitizer: Enabled XFA: Enabled V8: Enabled The attached pdf can be reproduced on pdfium f49747f(https://pdfium.googlesource.com/pdfium/+/f49747f5fc85ea2acf0c5ff0ab589ad791bf6648). This bug still exists. ( Issue 618264 has been closed and labeled as WontFix, can anyone help reopen that issue?)
,
Jun 12 2016
The root cause of this issue may be the same as Issue 618267.
,
Jun 16 2016
,
Jun 22 2016
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5934526224400384
,
Jun 29 2016
,
Oct 14 2016
,
Dec 5 2016
ClusterFuzz testcase is flaky and no longer reproduces, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Dec 6 2016
Hello, can we mark this issue as Verified instead of WontFix? Thanks.
,
Dec 6 2016
,
Dec 7 2016
,
Aug 29 2017
,
Sep 18 2017
We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.
,
Jan 30 2018
,
Jan 30 2018
Tested this again with XFA enabled, no longer reproduces
,
Feb 8 2018
,
May 9 2018
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 stackexp...@gmail.com
, Jun 10 2016