Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1683632 (CVE-2019-9200) - CVE-2019-9200 poppler: heap-based buffer overflow in function ImageStream::getLine() in Stream.cc
Summary: CVE-2019-9200 poppler: heap-based buffer overflow in function ImageStream::ge...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-9200
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1683633 1685267 1685268 1717803
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-27 12:23 UTC by Dhananjay Arunesh
Modified: 2019-09-29 15:08 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:22:01 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2022 0 None None None 2019-08-06 12:03:04 UTC
Red Hat Product Errata RHSA-2019:2713 0 None None None 2019-09-11 09:33:24 UTC

Description Dhananjay Arunesh 2019-02-27 12:23:37 UTC 
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
Comment 1 Dhananjay Arunesh 2019-02-27 12:23:48 UTC 
Created poppler tracking bugs for this issue:

Affects: fedora-all [bug 1683633]
Comment 2 Scott Gayou 2019-03-04 20:06:56 UTC 
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.
Comment 7 errata-xmlrpc 2019-08-06 12:03:03 UTC 
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
Comment 8 Product Security DevOps Team 2019-08-06 13:22:01 UTC 
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
Comment 9 errata-xmlrpc 2019-09-11 09:33:23 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.