Issue metadata
Sign in to add a comment
|
Security: PDFium: Heap Buffer Overflow in libtiff's EstimateStripByteCounts Function
Reported by
stackexp...@gmail.com,
Jun 10 2016
|
||||||||||||||||||||
Issue description
Security: PDFium: Heap Buffer Overflow in libtiff's EstimateStripByteCounts 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
----------------------------
==2822==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5c11e78 at pc 0x0c9770e7 bp 0xbf838438 sp 0xbf838430
WRITE of size 8 at 0xb5c11e78 thread T0
#0 0xc9770e6 in EstimateStripByteCounts out/Release/../../third_party/libtiff/tif_dirread.c:4336:7
#1 0xc958f09 in TIFFReadDirectory out/Release/../../third_party/libtiff/tif_dirread.c:3974:8
#2 0xc9abb0a in TIFFClientOpen out/Release/../../third_party/libtiff/tif_open.c:466:8
#3 0xc90be74 in (anonymous namespace)::tiff_open(void*, char const*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:138:15
#4 0xc90be74 in CCodec_TiffContext::InitDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:194
#5 0xc90be74 in CCodec_TiffModule::CreateDecoder(IFX_FileRead*) out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:436
#6 0xc8f70d8 in CCodec_ProgressiveDecoder::DetectImageType(FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1261:24
#7 0xc8f935c in CCodec_ProgressiveDecoder::LoadImageInfo(IFX_FileRead*, FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1319:9
#8 0xbf3f1bd in XFA_LoadImageFromBuffer(IFX_FileRead*, FXCODEC_IMAGE_TYPE, int&, int&) out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1072:3
#9 0xbf3ea77 in XFA_LoadImageData(CXFA_FFDoc*, CXFA_Image*, int&, int&, int&) out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1031:7
#10 0xbf50d88 in CXFA_ImageLayoutData::LoadImageData(CXFA_WidgetAcc*) out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:96:25
#11 0xbf4ec7d in CXFA_WidgetAcc::LoadImageImage() out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:1001:45
#12 0xc3827d5 in CXFA_FFImage::LoadWidget() out/Release/../../xfa/fxfa/app/xfa_ffimage.cpp:27:3
#13 0xbf0c50c in CXFA_FFPageWidgetIterator::GetWidget(CXFA_LayoutItem*) out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:192:7
#14 0xbf0cfa0 in CXFA_FFPageWidgetIterator::MoveToNext() out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:162:34
#15 0x81b12ef in CPDFSDK_PageView::LoadFXAnnots() out/Release/../../fpdfsdk/fsdk_mgr.cpp:927:39
#16 0x81b05cc in CPDFSDK_Document::GetPageView(CPDFXFA_Page*, int) out/Release/../../fpdfsdk/fsdk_mgr.cpp:274:3
#17 0x815281c in (anonymous namespace)::FormHandleToPageView(void*, void*) out/Release/../../fpdfsdk/fpdfformfill.cpp:45:20
#18 0x815281c in FORM_OnAfterLoadPage out/Release/../../fpdfsdk/fpdfformfill.cpp:642
#19 0x813eb7c in RenderPage(std::string const&, void* const&, void* const&, int, Options const&, std::string const&) out/Release/../../samples/pdfium_test.cc:497:3
#20 0x8140ceb in RenderPdf(std::string const&, char const*, unsigned int, Options const&, std::string const&) out/Release/../../samples/pdfium_test.cc:694:9
#21 0x8142d03 in main out/Release/../../samples/pdfium_test.cc:835:5
#22 0xb73ffa82 in __libc_start_main /build/eglibc-617sU_/eglibc-2.19/csu/libc-start.c:287
#23 0x807e5c3 in _start (out/Release/pdfium_test+0x807e5c3)
0xb5c11e78 is located 0 bytes to the right of 24-byte region [0xb5c11e60,0xb5c11e78)
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
SUMMARY: AddressSanitizer: heap-buffer-overflow out/Release/../../third_party/libtiff/tif_dirread.c:4336 EstimateStripByteCounts
Shadow bytes around the buggy address:
0x36b82370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36b82380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36b82390: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36b823a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36b823b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x36b823c0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00[fa]
0x36b823d0: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa 00 00
0x36b823e0: 00 fa fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
0x36b823f0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
0x36b82400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36b82410: 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 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
==2822==ABORTING
---------------------------
Source Code Information
---------------------------
4322 /*
4323 * This gross hack handles the case were the offset to
4324 * the last strip is past the place where we think the strip
4325 * should begin. Since a strip of data must be contiguous,
4326 * it's safe to assume that we've overestimated the amount
4327 * of data in the strip and trim this number back accordingly.
4328 */
4329 strip--;
4330 if (td->td_stripoffset[strip]+td->td_stripbytecount[strip] > filesize)
4331 td->td_stripbytecount[strip] = filesize - td->td_stripoffset[strip];
4332 } else if (isTiled(tif)) {
4333 uint64 bytespertile = TIFFTileSize64(tif);
4334
4335 for (strip = 0; strip < td->td_nstrips; strip++)
4336 td->td_stripbytecount[strip] = bytespertile; // <-------------------- Heap Buffer Overflow!!!!!!
4337 } else {
4338 uint64 rowbytes = TIFFScanlineSize64(tif);
4339 uint32 rowsperstrip = td->td_imagelength/td->td_stripsperimage;
4340 for (strip = 0; strip < td->td_nstrips; strip++)
4341 td->td_stripbytecount[strip] = rowbytes * rowsperstrip;
4342 }
---------------------------
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=5659814780993536
,
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=5246925381304320
,
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
With XFA enabled, this appears to be still reproducing
,
May 1 2018
I have rolled libtiff recently to the newest version (4.0.9) and this no longer occurs.
,
May 2 2018
,
Aug 8
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