Hide Forgot
In Poppler 0.73.0, a heap-based buffer over-read (due to an integer signedness error in the XRef::getEntry function in XRef.cc) allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted PDF document, as demonstrated by pdftocairo. References: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12797 https://gitlab.freedesktop.org/poppler/poppler/issues/717 Upstream Patch: https://gitlab.freedesktop.org/poppler/poppler/merge_requests/172
Created mingw-poppler tracking bugs for this issue: Affects: fedora-all [bug 1672421] Created poppler tracking bugs for this issue: Affects: fedora-all [bug 1672420]
Easy to reproduce: ``` ==28176== Invalid read of size 4 ==28176== at 0x4FA62B1: XRef::getEntry(int, bool) (XRef.cc:1609) ==28176== by 0x4F89FF6: Parser::makeStream(Object*, unsigned char*, CryptAlgorithm, int, int, int, int, bool) (Parser.cc:207) ==28176== by 0x4F8A8F7: Parser::getObj(Object*, bool, unsigned char*, CryptAlgorithm, int, int, int, int, bool) (Parser.cc:131) ==28176== by 0x4F6FA84: Hints::readTables(BaseStream*, Linearization*, XRef*, SecurityHandler*) (Hints.cc:145) ==28176== by 0x4F8B474: PDFDoc::getHints() (PDFDoc.cc:607) ==28176== by 0x4F90518: PDFDoc::parsePage(int) (PDFDoc.cc:1890) ==28176== by 0x4F90769: PDFDoc::getPage(int) (PDFDoc.cc:1931) ==28176== by 0x4087C5: getPageMediaWidth (PDFDoc.h:126) ==28176== by 0x4087C5: main (pdftocairo.cc:1014) ==28176== Address 0x9ffd444 is 28 bytes before a block of size 16 in arena "client" ==28176== ==28176== Invalid read of size 4 ==28176== at 0x4F8A003: Parser::makeStream(Object*, unsigned char*, CryptAlgorithm, int, int, int, int, bool) (Parser.cc:205) ==28176== by 0x4F8A8F7: Parser::getObj(Object*, bool, unsigned char*, CryptAlgorithm, int, int, int, int, bool) (Parser.cc:131) ==28176== by 0x4F6FA84: Hints::readTables(BaseStream*, Linearization*, XRef*, SecurityHandler*) (Hints.cc:145) ==28176== by 0x4F8B474: PDFDoc::getHints() (PDFDoc.cc:607) ==28176== by 0x4F90518: PDFDoc::parsePage(int) (PDFDoc.cc:1890) ==28176== by 0x4F90769: PDFDoc::getPage(int) (PDFDoc.cc:1931) ==28176== by 0x4087C5: getPageMediaWidth (PDFDoc.h:126) ==28176== by 0x4087C5: main (pdftocairo.cc:1014) ==28176== Address 0x9ffd448 is 24 bytes before a block of size 5 free'd ==28176== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==28176== by 0x4F96037: FlateStream::~FlateStream() (Stream.cc:4521) ==28176== by 0x4F96078: FlateStream::~FlateStream() (Stream.cc:4524) ==28176== by 0x4F83E73: Object::free() (Object.cc:145) ==28176== by 0x4FA5CBB: XRef::readXRef(long long*, std::vector<long long, std::allocator<long long> >*, std::vector<int, std::allocator<int> >*) (XRef.cc:562) ==28176== by 0x4FA5DEF: XRef::XRef(BaseStream*, long long, long long, bool*, bool) (XRef.cc:342) ==28176== by 0x4F8F327: PDFDoc::setup(GooString*, GooString*) (PDFDoc.cc:260) ==28176== by 0x4F8F627: PDFDoc::PDFDoc(GooString*, GooString*, GooString*, void*) (PDFDoc.cc:165) ==28176== by 0x4F829E3: LocalPDFDocBuilder::buildPDFDoc(GooString const&, GooString*, GooString*, void*) (LocalPDFDocBuilder.cc:31) ``` Looks like a negative index can get passed to XRef::getEntry by an attacker. ```c XRefEntry *XRef::getEntry(int i, GBool complainIfMissing) { if (i >= size || entries[i].type == xrefEntryNone) { if ((!xRefStream) && mainXRefEntriesOffset) { if (!parseEntry(mainXRefEntriesOffset + 20*i, &entries[i])) { error(errSyntaxError, -1, "Failed to parse XRef entry [{0:d}].", i); } } else { ... return &entries[i]; ``` Presumably, valgrind/ASAN is asserting when the entries[i] load occurs. Could then return a negative entry back to the caller. Unclear if this could lead to code execution, but rated the CVSS a bit higher to account for my uncertainty.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2019:2022 https://access.redhat.com/errata/RHSA-2019:2022
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-7310
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:2713 https://access.redhat.com/errata/RHSA-2019:2713