New issue
Advanced search Search tips

Issue 618264 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security

Blocking:
issue 62400
issue 656204



Sign in to add a comment

Security: PDFium: Out-Of-Bounds Read in libtiff's TIFFReadDirectory Function

Reported by stackexp...@gmail.com, Jun 8 2016

Issue description

Security: PDFium: Out-Of-Bounds Read in libtiff's TIFFReadDirectory Function

VULNERABILITY DETAILS
This Out-Of-Bounds Read 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
----------------------------
==6755==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb60082b8 at pc 0x0c8a3576 bp 0xbfd444b8 sp 0xbfd444b0
READ of size 8 at 0xb60082b8 thread T0
    #0 0xc8a3575 in TIFFReadDirectory pdfium/out/Release/../../third_party/libtiff/tif_dirread.c:4003:8
    #1 0xc8f33ea in TIFFClientOpen pdfium/out/Release/../../third_party/libtiff/tif_open.c:466:8
    #2 0xc853e1f in _tiff_open(void*, char const*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:158:15
    #3 0xc853e1f in CCodec_TiffContext::InitDecoder(IFX_FileRead*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:212
    #4 0xc853e1f in CCodec_TiffModule::CreateDecoder(IFX_FileRead*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:518
    #5 0xc83e4ba in CCodec_ProgressiveDecoder::DetectImageType(FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1238:24
    #6 0xc84077c in CCodec_ProgressiveDecoder::LoadImageInfo(IFX_FileRead*, FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1297:9
    #7 0xbf1948d in XFA_LoadImageFromBuffer(IFX_FileRead*, FXCODEC_IMAGE_TYPE, int&, int&) pdfium/out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1072:3
    #8 0xbf18d47 in XFA_LoadImageData(CXFA_FFDoc*, CXFA_Image*, int&, int&, int&) pdfium/out/Release/../../xfa/fxfa/app/xfa_ffwidget.cpp:1031:7
    #9 0xbf29cf8 in CXFA_ImageLayoutData::LoadImageData(CXFA_WidgetAcc*) pdfium/out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:96:25
    #10 0xbf27bed in CXFA_WidgetAcc::LoadImageImage() pdfium/out/Release/../../xfa/fxfa/app/xfa_ffwidgetacc.cpp:1002:45
    #11 0xc33c565 in CXFA_FFImage::LoadWidget() pdfium/out/Release/../../xfa/fxfa/app/xfa_ffimage.cpp:27:3
    #12 0xbee67dc in CXFA_FFPageWidgetIterator::GetWidget(CXFA_LayoutItem*) pdfium/out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:196:7
    #13 0xbee7270 in CXFA_FFPageWidgetIterator::MoveToNext() pdfium/out/Release/../../xfa/fxfa/app/xfa_ffpageview.cpp:166:34
    #14 0x81b573f in CPDFSDK_PageView::LoadFXAnnots() pdfium/out/Release/../../fpdfsdk/fsdk_mgr.cpp:921:39
    #15 0x81b4a1c in CPDFSDK_Document::GetPageView(CPDFXFA_Page*, int) pdfium/out/Release/../../fpdfsdk/fsdk_mgr.cpp:268:3
    #16 0x8156b1c in (anonymous namespace)::FormHandleToPageView(void*, void*) pdfium/out/Release/../../fpdfsdk/fpdfformfill.cpp:45:20
    #17 0x8156b1c in FORM_OnAfterLoadPage pdfium/out/Release/../../fpdfsdk/fpdfformfill.cpp:642
    #18 0x813ec8c in RenderPage(std::string const&, void* const&, void* const&, int, Options const&, std::string const&) pdfium/out/Release/../../samples/pdfium_test.cc:497:3
    #19 0x8140dfb in RenderPdf(std::string const&, char const*, unsigned int, Options const&, std::string const&) pdfium/out/Release/../../samples/pdfium_test.cc:694:9
    #20 0x8146fea in main pdfium/out/Release/../../samples/pdfium_test.cc:1282:5
    #21 0xb741fa82 in __libc_start_main /build/eglibc-617sU_/eglibc-2.19/csu/libc-start.c:287
    #22 0x807e6c3 in _start (pdfium/out/Release/pdfium_test+0x807e6c3)

0xb60082b8 is located 0 bytes to the right of 8-byte region [0xb60082b0,0xb60082b8)
allocated by thread T0 here:
    #0 0x8116709 in realloc (pdfium/out/Release/pdfium_test+0x8116709)
    #1 0xc84e0be in _TIFFrealloc pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:173:10
    #2 0xc89f519 in TIFFReadDirectory pdfium/out/Release/../../third_party/libtiff/tif_dirread.c:3722:10
    #3 0xc8f33ea in TIFFClientOpen pdfium/out/Release/../../third_party/libtiff/tif_open.c:466:8
    #4 0xc853e1f in _tiff_open(void*, char const*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:158:15
    #5 0xc853e1f in CCodec_TiffContext::InitDecoder(IFX_FileRead*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:212
    #6 0xc853e1f in CCodec_TiffModule::CreateDecoder(IFX_FileRead*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_tiff.cpp:518
    #7 0xc84077c in CCodec_ProgressiveDecoder::LoadImageInfo(IFX_FileRead*, FXCODEC_IMAGE_TYPE, CFX_DIBAttribute*) pdfium/out/Release/../../core/fxcodec/codec/fx_codec_progress.cpp:1297:9

SUMMARY: AddressSanitizer: heap-buffer-overflow pdfium/out/Release/../../third_party/libtiff/tif_dirread.c:4003 TIFFReadDirectory
Shadow bytes around the buggy address:
  0x36c01000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36c01010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36c01020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36c01030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36c01040: fa fa fa fa fa fa fa fa fa fa 00 fa fa fa fd fa
=>0x36c01050: fa fa fd fa fa fa 00[fa]fa fa fd fa fa fa fd fa
  0x36c01060: fa fa fd fa fa fa 00 00 fa fa fd fd fa fa fd fa
  0x36c01070: fa fa fd fd fa fa fd fd fa fa 04 fa fa fa 04 fa
  0x36c01080: fa fa 00 00 fa fa 00 fa fa fa 00 fa fa fa fd fa
  0x36c01090: fa fa 00 04 fa fa 04 fa fa fa fd fd fa fa fd fd
  0x36c010a0: fa fa 00 04 fa fa fd fd fa fa fd fd fa fa fd fd
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
==6755==ABORTING

---------------------------
Source Code Information
---------------------------
3996 #if !defined(DEFER_STRILE_LOAD)        
3997 	if (tif->tif_dir.td_nstrips > 1) {
3998 		uint32 strip;
3999 
4001 		tif->tif_dir.td_stripbytecountsorted = 1;
4002 		for (strip = 1; strip < tif->tif_dir.td_nstrips; strip++) {
4003 			if (tif->tif_dir.td_stripoffset[strip - 1] >    // <------------------------- OOB Access!!!
4004 			    tif->tif_dir.td_stripoffset[strip]) {
4005 				tif->tif_dir.td_stripbytecountsorted = 0;
4006 				break;
4007 			}
4008 		}
4009 	}
4010 #endif /* !defined(DEFER_STRILE_LOAD) */

---------------------------
PoC Diff
---------------------------
I've already did some difference reduction work. I'll attach the minimized proof-of-concept file. Two bytes were changed to trigger this vulnerability.
1. The value member of the ImageLength directory was changed from 0x00000001 (01 00 00 00) to 0x40000001 (01 00 00 40).
2. The tag member of the YResolution directory was changed from 0x011B (1B 01) to 0x013B (3B 01). In other words, the YResolution directory was treated as an Artist directory.

VERSION
Chrome Version: [Beta]
Operating System: [Windows 7 SP1]

REPRODUCTION CASE
Both the original normal tiff file, 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]

 

Comment 1 Deleted

Hi, you can try to test my PoC with ClusterFuzz directly. If the test result indicates a null pointer dereference, then you should fix the tif_ctx initialization problem first.
This is waiting on the fix in https://codereview.chromium.org/2053573003
Components: Internals>Plugins>PDF

Comment 5 by och...@chromium.org, Jun 10 2016

Owner: hong_zh...@foxitsoftware.com
Project Member

Comment 6 by ClusterFuzz, Jun 10 2016

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5706569341992960
Status: WontFix (was: Unconfirmed)
Clusterfuzz can't repro using the attached pdf.

Comment 8 Deleted

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.

Can anyone help me to reopen this issue? Thanks very much.
Status: Assigned (was: WontFix)
Labels: Security_Severity-Medium Security_Impact-None
yup, this was closed before I got word that XFA was disabled. So currently we can't repro this, but we'll hang onto it for Hong to look at during efforts to re-enable XFA, if that's the plan.
Project Member

Comment 12 by ClusterFuzz, Jun 14 2016

Labels: ClusterFuzz-Verified
Status: Verified (was: Assigned)
ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
Labels: -ClusterFuzz-Verified
Status: Assigned (was: Verified)
Sorry for the incorrect ClusterFuzz update, please ignore it. Reopening bug.
Blocking: 62400
Project Member

Comment 15 by ClusterFuzz, Jun 22 2016

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6488168144830464
Blocking: 656204
Project Member

Comment 17 by ClusterFuzz, Dec 5 2016

Status: WontFix (was: Assigned)
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.
Hello, can we mark this issue as Verified instead of WontFix? Thanks.
Labels: ClusterFuzz-Wrong
Status: Available (was: WontFix)
Project Member

Comment 20 by sheriffbot@chromium.org, Dec 7 2016

Status: Assigned (was: Available)
Labels: reward-NA
Labels: -ClusterFuzz-Wrong
We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.
Owner: rharrison@chromium.org
Status: Fixed (was: Assigned)
Recently updated libtiff to teh newest version, not able to reproduce this issue.
Project Member

Comment 25 by sheriffbot@chromium.org, May 2 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 26 by sheriffbot@chromium.org, Aug 8

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