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...
Status: NEW
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: impact=moderate,public=20190225,repor...
Keywords: Security
Depends On: 1685267 1685268 1717803 1683633
Blocks: 1683635
TreeView+ depends on / blocked
 
Reported: 2019-02-27 12:23 UTC by Dhananjay Arunesh
Modified: 2019-06-08 23:53 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.