Bug 1672419 (CVE-2019-7310)

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