Pdfium: out-of-bounds read with nested colorspaces 




The PDF specification allows multiple methods of specifying the colorspace to be used for rendering a drawing, several of which allow the "nesting" of different colorspaces. In all of these cases, the specification places restrictions on the "nestings" which are allowed, usually requiring that the nested colorspace is not a pattern-type colorspace.

This requirement is not enforced in pdfium, which provides some interesting opportunities. The implementation of all standard colorspaces provide the following API

CPDF_ColorSpace::GetRGB(float* pBuf, float* R, float *G, float* B)

in which pBuf is a pointer to a buffer large enough to contain one float for every component of the colorspace. 

However, for pattern colorspaces the semantics of this method are different

bool CPDF_PatternCS::GetRGB(float* pBuf, float* R, float* G, float* B) const {
  if (m_pBaseCS) {
    ASSERT(m_pBaseCS->GetFamily() != PDFCS_PATTERN);
    PatternValue* pvalue = (PatternValue*)pBuf;
    if (m_pBaseCS->GetRGB(pvalue->m_Comps, R, G, B))
      return true;
  }
  *R = 0.75f;
  *G = 0.75f;
  *B = 0.75f;
  return false;
}

where this input float array is cast to an object of type PatternValue.

By nesting colorspaces, we can create a situation where this input buffer is smaller than a PatternValue, and then the base colorspace of our pattern colorspace can process out-of-bounds memory as it's input components.

The attached PDF triggers an oob-read under ASAN on the latest chrome-linux-asan build. 

It should be possible to use this to leak heap memory (at least to the screen), but I haven't tried to put together a heap groom to get any interesting data following the allocation.

The PoC works by creating an ICCBased colorspace with a pattern colorspace backed by a devicen colorspace as the alternate colorspace 

<<
  /N 4
  /Alternate [/Pattern [/DeviceN [/Col0 /Col1 /Col2] /DeviceRGB ...]]
...
>>

and then configuring this colorspace and setting the fill color, triggering the out-of-bounds read. The devicen colorspace provides a function mapping the input components to the devicergb colorspace via a simple postscript function.

There are several other related paths which lead to potentially undesirable behavior caused by nesting pattern colorspaces, including some reads of uninitialised stack memory, but I didn't see a path to memory corruption.

Originally reported without 90 day deadline as <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=794492" title="" class="" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=794492</a>, since it wasn't clear that there was an easy way to use the oob-read to leak information in a way that was useful, deadline applied as of 15/12 after working out how to use this as an information leak for <a href="/p/project-zero/issues/detail?id=1489" title="Pdfium: integer overflows in pattern shading" class="closed_ref" rel="nofollow"> issue 1489 </a>. 

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.




Found by: markbrand