what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Pdfium Colorspaces Out-Of-Bounds Read

Pdfium Colorspaces Out-Of-Bounds Read
Posted Feb 15, 2018
Authored by Google Security Research, Mark Brand

Pdfium suffers from an out-of-bounds read vulnerability with nested colorspaces.

tags | advisory
SHA-256 | 12f03767c9d43e8a501e1d3a1b41c4dd55373be4fd2eac5418f3d65528b4290b

Pdfium Colorspaces Out-Of-Bounds Read

Change Mirror Download
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

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close