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)

Summary: CVE-2019-9200 poppler: heap-based buffer overflow in function ImageStream::getLine() in Stream.cc
Product: [Other] Security Response Reporter: Dhananjay Arunesh <darunesh>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: caillon+fedoraproject, feborges, gnome-sig, john.j5live, mclasen, mkasik, rdieter, rhughes, rstrode, sandmann
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 13:22:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1683633, 1685267, 1685268, 1717803    
Bug Blocks:    

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