Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 01 Feb 2017 16:09:29 +0100
From: Agostino Sarubbo <ago@...too.org>
To: oss-security@...ts.openwall.com
Subject: podofo: infinite loop in PoDoFo::PdfPage::GetInheritedKeyFromObject (PdfPage.cpp)

Description:
podofo is a C++ library to work with the PDF file format.

A fuzz on it discovered an infinite loop. The upstream project denies me to 
open a new ticket. So, I’m unable to communicate with them.

The complete ASan output:

# podofopdfinfo $FILE
==8407==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcff058fe0 (pc 
0x000000425a5f bp 0x6400000003f0 sp 0x7ffcff058fe0 T0)
    #0 0x425a5e in GenericScopedLock /tmp/portage/sys-devel/llvm-3.9.0-
r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:179
    #1 0x425a5e in __sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>::PopulateFreeList(__sanitizer::AllocatorStats*, 
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>*, unsigned long, __sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>::RegionInfo*) /tmp/portage/sys-devel/llvm-3.9.0-
r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:540
    #2 0x426297 in __sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>::AllocateBatch(__sanitizer::AllocatorStats*, 
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>*, unsigned long) /tmp/portage/sys-devel/llvm-3.9.0-
r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:359
    #3 0x4262f6 in 
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>::Refill(__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>*, unsigned long) /tmp/portage/sys-
devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1003
    #4 0x4298ed in 
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>::Allocate(__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>*, unsigned long) /tmp/portage/sys-
devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:952
    #5 0x4298ed in 
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, 
__asan::AsanMapUnmapCallback>, 
__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>, __sanitizer::LargeMmapAllocator 
>::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 
4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> 
>*, unsigned long, unsigned long, bool, bool) /tmp/portage/sys-
devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1324
    #6 0x4298ed in __asan::Allocator::Allocate(unsigned long, unsigned long, 
__sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /tmp/portage/sys-
devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/asan_allocator.cc:368
    #7 0x50e8b8 in operator new(unsigned long) /tmp/portage/sys-
devel/llvm-3.9.0-r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/asan_new_delete.cc:78
    #8 0x7f2e77512621 in PoDoFo::PdfVariant::PdfVariant(PoDoFo::PdfDictionary 
const&) /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVariant.cpp:151:20
    #9 0x7f2e77495f6d in PoDoFo::PdfObject::PdfObject(PoDoFo::PdfReference 
const&, char const*) /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfObject.cpp:62:7
    #10 0x7f2e7751dcf8 in 
PoDoFo::PdfVecObjects::GetObject(PoDoFo::PdfReference const&) const 
/tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfVecObjects.cpp:151:15
    #11 0x7f2e7749afe1 in PoDoFo::PdfObject::GetIndirectKey(PoDoFo::PdfName 
const&) const /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/base/PdfObject.cpp:237:30
    #12 0x7f2e77741533 in PoDoFo::PdfPage::GetInheritedKeyFromObject(char 
const*, PoDoFo::PdfObject const*) const /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/doc/PdfPage.cpp:230:26
    #13 0x7f2e777415a4 in PoDoFo::PdfPage::GetInheritedKeyFromObject(char 
const*, PoDoFo::PdfObject const*) const /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/doc/PdfPage.cpp:232:20
    [.....]
    #254 0x7f2e777415a4 in PoDoFo::PdfPage::GetInheritedKeyFromObject(char 
const*, PoDoFo::PdfObject const*) const /tmp/portage/app-
text/podofo-0.9.4/work/podofo-0.9.4/src/doc/PdfPage.cpp:232:20

SUMMARY: AddressSanitizer: stack-overflow /tmp/portage/sys-devel/llvm-3.9.0-
r1/work/llvm-3.9.0.src/projects/compiler-
rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:179 in GenericScopedLock
==8407==ABORTING

Affected version:
0.9.4

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Reproducer:
https://github.com/asarubbo/poc/blob/master/00145-podofo-infiniteloop-PdfPage

Timeline:
2017-01-05: bug discovered
2017-02-01: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:
https://blogs.gentoo.org/ago/2017/02/01/podofo-infinite-loop-in-podofopdfpagegetinheritedkeyfromobject-pdfpage-cpp

-- 
Agostino Sarubbo
Gentoo Linux Developer

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.