Issue metadata
Sign in to add a comment
|
Security: Stack Overflow in pdfium (JBig2_Image.cp)
Reported by
tmm...@acu.edu,
Sep 25 2016
|
||||||||||||||||||||||
Issue descriptionFor sufficiently large values of m_nStrides, it is possible to write data directly to the stack in the setPixel function (https://pdfium.googlesource.com/pdfium/+/master/core/fxcodec/jbig2/JBig2_Image.cpp#91) Here, an m_nStride value(Set when the image is first created) is multiplied by the user supplied y. This will make the follow up line m_pData[m] |= 1 << (7 - n) attempt to | data into m_pData. I've attached my POC that triggers this via direct API calls. The pertinent test is setPixelStackWrite. There is another similar crash in getPixelStackRead, but it's only a read. OS: Ubuntu 16.04.1 LTS Kernel version 4.4 Version: PDFIUM standalone
,
Sep 25 2016
,
Sep 25 2016
A little more info: core/fxcodec/jbig2/JBig2_Context.cpp:175 appears to be the only function that calls the proper method: m_pPage.reset(new CJBig2_Image(width, height, stride, pBuf)) This call is reachable via a pdf with a jbig image (Such as the example here: https://bugs.chromium.org/p/pdfium/issues/detail?id=511). A write what where, for limited values of what
,
Sep 26 2016
,
Sep 27 2016
It's not immediately obvious if the values passed directly to the CJBig2_Image ctor are actually possible in the one and only path that actually call that ctor.
,
Sep 27 2016
+ochang as well for more eyes. 1) The "direct API calls" statement is flawed. The CJBig2_Image ctor is not directly accessible to the user. 2) The only way to access the ctor is via CPDF_DIBSource::ContinueLoadDIBSource() -> CCodec_Jbig2Module::StartDecode() -> CJBig2_Context::getFirstPage(). 3) And thus the buffer that is being passed in can only come from a few places in CFX_DIBitmap::Create() and CFX_DIBitmap::ConvertFormat(). 4) In most cases in (3), the size of the buffer is calculate from the pitch/height. It cannot be arbitrarily set to a size that's too small like in the POC. Thus I am leaning towards WontFix, as the POC cannot happen with real PDFium code in its entirety.
,
Sep 27 2016
Another way of looking at this is: Can you make a PDF file with a specially crafted JBIG image inside that triggers an overflow in setPixel()?
,
Sep 28 2016
Someone from security should read my analysis and retriage.
,
Sep 28 2016
Please re-open if you can produce a crafted JBIG image file that triggers this.
,
Jan 5 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Sep 25 2016Labels: Security_Severity-High Security_Impact-Stable Pri-1
Owner: thestig@chromium.org
Status: Assigned (was: Unconfirmed)