A heap-based buffer underwrite exists in ImageStream::getLine() located at Stream.cc in Poppler 0.74.0 that can (for example) be triggered by sending a crafted PDF file to the pdfimages binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact. Reference: https://gitlab.freedesktop.org/poppler/poppler/issues/728
Created poppler tracking bugs for this issue: Affects: fedora-all [bug 1683633]
Red Hat Enterprise 5 and 6 do not look vulnerable based on testing the POC and a brief source code review. For 7, the output is a bit different than upstream: ``` ==13493== Memcheck, a memory error detector ==13493== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13493== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==13493== Command: pdfimages -f 1 -l 1 -opw testing -upw testing -j -p -q poc outputfile ==13493== ==13493== Use of uninitialised value of size 8 ==13493== at 0x4F5D424: GfxImageColorMap::getGray(unsigned char*, int*) (GfxState.cc:5872) ==13493== by 0x404EBC: ImageOutputDev::writeImageFile(ImgWriter*, ImageOutputDev::ImageFormat, char const*, Stream*, int, int, GfxImageColorMap*) (ImageOutputDev.cc:360) ==13493== by 0x40577E: ImageOutputDev::writeImage(GfxState*, Object*, Stream*, int, int, GfxImageColorMap*, bool) (ImageOutputDev.cc:582) ==13493== by 0x4F4673D: Gfx::doImage(Object*, Stream*, bool) (Gfx.cc:4654) ==13493== by 0x4F46FD9: Gfx::opBeginImage(Object*, int) (Gfx.cc:4978) ==13493== by 0x4F41B50: Gfx::go(bool) (Gfx.cc:763) ==13493== by 0x4F41FAC: Gfx::display(Object*, bool) (Gfx.cc:729) ==13493== by 0x4F423B1: Gfx::drawForm(Object*, Dict*, double*, double*, bool, bool, GfxColorSpace*, bool, bool, bool, Function*, GfxColor*) (Gfx.cc:4922) ==13493== by 0x4F475E8: Gfx::doForm(Object*) (Gfx.cc:4845) ==13493== by 0x4F47B59: Gfx::opXObject(Object*, int) (Gfx.cc:4199) ==13493== by 0x4F41B50: Gfx::go(bool) (Gfx.cc:763) ==13493== by 0x4F41FAC: Gfx::display(Object*, bool) (Gfx.cc:729) ==13493== ==13493== ==13493== HEAP SUMMARY: ==13493== in use at exit: 12,861 bytes in 29 blocks ==13493== total heap usage: 6,165 allocs, 6,136 frees, 996,569 bytes allocated ==13493== ==13493== LEAK SUMMARY: ==13493== definitely lost: 0 bytes in 0 blocks ==13493== indirectly lost: 0 bytes in 0 blocks ==13493== possibly lost: 0 bytes in 0 blocks ==13493== still reachable: 12,861 bytes in 29 blocks ==13493== suppressed: 0 bytes in 0 blocks ==13493== Rerun with --leak-check=full to see details of leaked memory ==13493== ``` Verified that readChars doesn't seem to get set to -1 on the 7 poc via GDB, but it looks vulnerable based on the code.
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-9200
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