Issue metadata
Sign in to add a comment
|
heap-use-after-free in ProbeForLowSeverityLifetimeIssue
Reported by
attek...@gmail.com,
Dec 18 2017
|
||||||||||||||||||||||
Issue description
Tested on:
OS: Ubuntu 16.04
Chrome: ASAN build asan-linux-release-524751
Tested to reproduce with ASAN build Chrome, pdfium_test and pdfium_fuzzer. On Chrome you might need to refresh the page to trigger the crash.
ASAN-trace:
:$ ./pdfium_fuzzer ./heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf
INFO: Seed: 4203392587
INFO: Loaded 2 modules (485466 guards): 22628 [0x7fe9abf44660, 0x7fe9abf5a7f0), 462838 [0x38ed2b0, 0x3ab1288),
/home/attekett/git/chrome/src/out/libfuzzer/pdfium_fuzzer: Running 1 inputs 1 time(s) each.
Running: ./heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf
=================================================================
==24905==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c00000bec0 at pc 0x000002d5cb50 bp 0x7ffdd00bd120 sp 0x7ffdd00bd118
READ of size 1 at 0x60c00000bec0 thread T0
#0 0x2d5cb4f in ProbeForLowSeverityLifetimeIssue third_party/pdfium/core/fxcrt/unowned_ptr.h:100:7
#1 0x2d5cb4f in ~UnownedPtr third_party/pdfium/core/fxcrt/unowned_ptr.h:52
#2 0x2d5cb4f in ~CPDF_ShadingObject third_party/pdfium/core/fpdfapi/page/cpdf_shadingobject.cpp:14
#3 0x2d5cb4f in CPDF_ShadingObject::~CPDF_ShadingObject() third_party/pdfium/core/fpdfapi/page/cpdf_shadingobject.cpp:14
#4 0x2d14f12 in operator() buildtools/third_party/libc++/trunk/include/memory:2233:5
#5 0x2d14f12 in reset buildtools/third_party/libc++/trunk/include/memory:2546
#6 0x2d14f12 in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2500
#7 0x2d14f12 in destroy buildtools/third_party/libc++/trunk/include/memory:1814
#8 0x2d14f12 in __destroy<std::__1::unique_ptr<CPDF_PageObject, std::__1::default_delete<CPDF_PageObject> > > buildtools/third_party/libc++/trunk/include/memory:1682
#9 0x2d14f12 in destroy<std::__1::unique_ptr<CPDF_PageObject, std::__1::default_delete<CPDF_PageObject> > > buildtools/third_party/libc++/trunk/include/memory:1550
#10 0x2d14f12 in std::__1::__deque_base<std::__1::unique_ptr<CPDF_PageObject, std::__1::default_delete<CPDF_PageObject> >, std::__1::allocator<std::__1::unique_ptr<CPDF_PageObject, std::__1::default_delete<CPDF_PageObject> > > >::clear() buildtools/third_party/libc++/trunk/include/deque:1168
#11 0x2d135bd in ~__deque_base buildtools/third_party/libc++/trunk/include/deque:1105:5
#12 0x2d135bd in CPDF_PageObjectHolder::~CPDF_PageObjectHolder() third_party/pdfium/core/fpdfapi/page/cpdf_pageobjectholder.cpp:30
#13 0x2d022c3 in ~CPDF_Form third_party/pdfium/core/fpdfapi/page/cpdf_form.cpp:32:26
#14 0x2d022c3 in CPDF_Form::~CPDF_Form() third_party/pdfium/core/fpdfapi/page/cpdf_form.cpp:32
#15 0x2d56bee in operator() buildtools/third_party/libc++/trunk/include/memory:2233:5
#16 0x2d56bee in reset buildtools/third_party/libc++/trunk/include/memory:2546
#17 0x2d56bee in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2500
#18 0x2d56bee in ~CPDF_FormObject third_party/pdfium/core/fpdfapi/page/cpdf_formobject.cpp:17
#19 0x2d56bee in CPDF_FormObject::~CPDF_FormObject() third_party/pdfium/core/fpdfapi/page/cpdf_formobject.cpp:17
#20 0x2d14f12 in operator() buildtools/third_party/libc++/trunk/include/memory:2233:5
.
.
.
0x60c00000bec0 is located 0 bytes inside of 128-byte region [0x60c00000bec0,0x60c00000bf40)
freed by thread T0 here:
#0 0xa7a5b2 in operator delete(void*) /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_new_delete.cc:149:3
#1 0x2cb5f1e in clear third_party/pdfium/core/fpdfapi/page/cpdf_countedobject.h:27:5
#2 0x2cb5f1e in CPDF_DocPageData::Clear(bool) third_party/pdfium/core/fpdfapi/page/cpdf_docpagedata.cpp:76
#3 0x2cb5076 in CPDF_DocPageData::~CPDF_DocPageData() third_party/pdfium/core/fpdfapi/page/cpdf_docpagedata.cpp:37:3
#4 0x2da83b1 in operator() buildtools/third_party/libc++/trunk/include/memory:2233:5
#5 0x2da83b1 in reset buildtools/third_party/libc++/trunk/include/memory:2546
#6 0x2da83b1 in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2500
#7 0x2da83b1 in CPDF_Document::~CPDF_Document() third_party/pdfium/core/fpdfapi/parser/cpdf_document.cpp:358
#8 0x2da856c in CPDF_Document::~CPDF_Document() third_party/pdfium/core/fpdfapi/parser/cpdf_document.cpp:356:33
#9 0xa7c0a7 in operator() third_party/pdfium/public/cpp/fpdf_deleters.h:26:47
#10 0xa7c0a7 in reset buildtools/third_party/libc++/trunk/include/memory:2546
.
.
.
previously allocated by thread T0 here:
#0 0xa799d2 in operator new(unsigned long) /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_new_delete.cc:92:3
#1 0x2cbb66b in MakeUnique<CPDF_ShadingPattern, CPDF_Document *, CPDF_Object *&, bool, const CFX_Matrix &> third_party/pdfium/third_party/base/ptr_util.h:56:29
#2 0x2cbb66b in CPDF_DocPageData::GetPattern(CPDF_Object*, bool, CFX_Matrix const&) third_party/pdfium/core/fpdfapi/page/cpdf_docpagedata.cpp:345
#3 0x2d4bfc1 in CPDF_StreamContentParser::FindPattern(fxcrt::ByteString const&, bool) third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:1223:23
#4 0x2d40afe in CPDF_StreamContentParser::Handle_ShadeFill() third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:1105:28
#5 0x2d4e810 in CPDF_StreamContentParser::Parse(unsigned char const*, unsigned int, unsigned int) third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:1530:9
#6 0x2c9453d in CPDF_ContentParser::Continue(IFX_PauseIndicator*) third_party/pdfium/core/fpdfapi/page/cpdf_contentparser.cpp:170:24
#7 0x2d13b5c in CPDF_PageObjectHolder::ContinueParse(IFX_PauseIndicator*) third_party/pdfium/core/fpdfapi/page/cpdf_pageobjectholder.cpp:40:18
#8 0x2d49f88 in CPDF_StreamContentParser::AddForm(CPDF_Stream*) third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:775:9
#9 0x2d30d52 in CPDF_StreamContentParser::Handle_ExecuteXObject() third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:763:5
#10 0x2d4e810 in CPDF_StreamContentParser::Parse(unsigned char const*, unsigned int, unsigned int) third_party/pdfium/core/fpdfapi/page/cpdf_streamcontentparser.cpp:1530:9
.
.
.
SUMMARY: AddressSanitizer: heap-use-after-free third_party/pdfium/core/fxcrt/unowned_ptr.h:100:7 in ProbeForLowSeverityLifetimeIssue
Shadow bytes around the buggy address:
0x0c187fff9780: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
0x0c187fff9790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c187fff97a0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c187fff97b0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
0x0c187fff97c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
=>0x0c187fff97d0: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
0x0c187fff97e0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c187fff97f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9820: 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
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
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
==24905==ABORTING
,
Dec 18 2017
Thank you for the report. This was already fixed by https://pdfium-review.googlesource.com/c/pdfium/+/21530
,
Dec 18 2017
No, this still shows up at ToT. Low Severity -> P2.
,
Dec 19 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5474914248425472.
,
Dec 19 2017
A one-byte read heap use-after-free in an unprivileged process would be considered Medium severity, which would still be P1 (despite the test case name). Clusterfuzz is being a little flakey on the test case despite my attempt at adding gestures to refresh the PDF (per the reporter's instructions and my local reproduction testing on linux-asan), but has confirmed the crash. Assigning to dsinclair@ due to git-blame on the unowned pointer.
,
Dec 19 2017
Low priority, per "ProbeFor _LowSeverity_ LifetimeIssue" in the name. I can try to help take a look this week if needed. Always busy right before the holidays.
,
Dec 19 2017
"LowSeverity" in the issue name comes from the first frame of the ASAN-trace, it is not the security severity. #0 0x2d5cb4f in ProbeForLowSeverityLifetimeIssue third_party/pdfium/core/fxcrt/unowned_ptr.h:100:7 Did you try using pdfium_test, instead of Chrome, on ClusterFuzz? On my tests pdfium_test reproduced the issue reliably.
,
Dec 19 2017
It is intended to give security bug triage folks a hint for the severity level. It came from https://pdfium.googlesource.com/pdfium.git/+/f677e18c985646c4ae1c5ec36445cdbf6bf78a6a I tried with pdfium_fuzzer as indicated in the original bug report.
,
Dec 19 2017
,
Dec 19 2017
I tested with pdfium_test, and https://pdfium-review.googlesource.com/c/pdfium/+/21530 did fix the crash using this repro step. @ ~/repo/pdfium ((667fa571d...))$ git checkout 175f01bb081b262fac00e8d0d331cb9661193554 Previous HEAD position was 667fa571d... Validate base color space of Indexed color spaces. HEAD is now at 175f01bb0... Configure CQ to use Windows ASAN bots. @ ~/repo/pdfium ((175f01bb0...))$ ninja -C out/Debug pdfium_all && out/Debug/pdfium_test ~/Downloads/heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf ninja: Entering directory `out/Debug' ninja: no work to do. Rendering PDF file /usr/local/google/home/hnakashima/Downloads/heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf. Received signal 11 SEGV_MAPERR 000000000010 ==== C stack trace =============================== [0x000001ece3c5] [...] [0x000000893029] [end of stack trace] Segmentation fault (core dumped) @ ~/repo/pdfium ((175f01bb0...))$ git checkout 682118834b3cf2b5510ee676088fdd8f11869e84 Previous HEAD position was 175f01bb0... Configure CQ to use Windows ASAN bots. HEAD is now at 682118834... Fix null-dereference in CPDF_ShadingPattern::Load(). @ ~/repo/pdfium ((682118834...))$ ninja -C out/Debug pdfium_all && out/Debug/pdfium_test ~/Downloads/heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf ninja: Entering directory `out/Debug' [8/8] STAMP obj/pdfium_all.stamp Rendering PDF file /usr/local/google/home/hnakashima/Downloads/heap-use-after-free-ProbeForLowSeverityLifetimeIssue.pdf. Rendered 1 pages. I'll try with pdfium_fuzzer now.
,
Dec 19 2017
Okay, this is not the same as bug 795490 and has been broken for a while. Reproduces at tip of tree with ASAN + pdfium_test.
,
Dec 19 2017
,
Dec 19 2017
Re C8, no thats exactly what it means. Don't make me change the name to ProbeForSecuritySerertiyLowIssuseThisIsLowSeverityYouGuysForRealz().
,
Dec 19 2017
Or FileThisAsLowSeverityIReallyMeanItThisIsntJustANameImTalkingToYou()
,
Dec 19 2017
,
Dec 19 2017
The following revision refers to this bug: https://pdfium.googlesource.com/pdfium/+/8ab9f80a944c16000f6a6f15366dd3704d315401 commit 8ab9f80a944c16000f6a6f15366dd3704d315401 Author: Henrique Nakashima <hnakashima@chromium.org> Date: Tue Dec 19 18:35:43 2017 Require valid color space for shading pattern. Bug: chromium:795889 Change-Id: If29a0f6f7d95bedf014464239da1f8b56e55c9b6 Reviewed-on: https://pdfium-review.googlesource.com/21750 Commit-Queue: Henrique Nakashima <hnakashima@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> [modify] https://crrev.com/8ab9f80a944c16000f6a6f15366dd3704d315401/core/fpdfapi/page/cpdf_shadingpattern.cpp
,
Dec 19 2017
,
Dec 19 2017
@tsepez, :D Never saw that kind of indicator in a stack frame, thought that it was just a weird function name. Next time I'll know. :) I take it that this issue wasn't duplicate after all. Could someone throw in reward-topanel?
,
Dec 19 2017
,
Dec 20 2017
,
Jan 6 2018
Hi attekett@ - the panel looked at this, and would be interested in seeing what happens if you try to reproduce after removing the ProbeForLowSeverityLifetimeIssue() check. There's a chance it might be masking a higher severity issue, but in most cases it is indeed a low severity issue.
,
Mar 28 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 elawrence@chromium.org
, Dec 18 2017