search

ITh4cker / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows Kernel ATMFD.DLL out-of-bounds reads from the input CharString stream #174

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The Type1/CFF CharString interpreter code in the Adobe Type Manager Font Driver 
(ATMFD.DLL) Windows kernel module does not check if the input stream pointer 
has not gone beyond the end of the source buffer, which stores the state 
machine instructions.

The unbounded reads can happen:

1) At the beginning of the VM execution loop (reading main opcode).
2) While reading the second opcode byte in case of the 'escape' instruction.
3) While reading the 'extendedmbr' instruction parameter, or the 16/32-bit 
numeric value to be pushed onto the interpreter stack.

This may result in the following outcomes:

1) The parser reads garbage, uninitialized or left-over data and interprets 
them as CharString instructions, potentially leading to disclosure of paged 
pool memory to userland through the glyphs' shapes. One especially prevalent 
example of information disclosure can be reproduced if a regular font is loaded 
in the system, followed by one with empty CharString streams. Frequently the 
buffers for the latter font will get re-allocated to where the original font's 
data was placed, and the system will raster the first font's glyphs in place of 
the non-existant second font's glyphs. This is an obvious information 
disclosure condition.

2) The parser reaches the end of a mapped memory page and attempts to read 
bytes beyond it, consequently resulting in a system crash and a Denial of 
Service condition.

A Proof of Concept file was prepared to demonstrate (2). The attached Type-1 
font ("poc.pfm" + "poc.pfb") includes 5452 "0 0 rmoveto" commands for character 
" " (SPACE), which results in a large pool allocation of 0x4000 bytes 
containing the instruction bytes, where controlled opcodes span between offsets 
0x18 to 0x3ffc of the allocated memory pages. In our test environment with a 
freshly started Windows 8.1 32-bit system, such 16kB-long allocation is not 
followed by any other mapped memory, and so crossing its boundary results in an 
immediate system crash.

Attached is also the Type1 source code of the POC font, "poc.pfa" (can be 
compiled with the "type1" utility of AFDKO). In order to reproduce, it is 
sufficient to open the font with the standard Windows Font Viewer tool, which 
should trigger the following or similar kernel crash (for a more detailed log, 
see "crash.txt"):

---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: 88a0f000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 9956dec8, If non-zero, the instruction address which referenced the bad 
memory
    address.
Arg4: 00000000, (reserved)

---

All supported Windows editions up to Windows 8.1 (regardless of bitness) are 
affected. We have confirmed that a system crash is possible using Type1 fonts; 
due to the architecture of loading OTF fonts (CharString source buffer 
typically residing in user-land memory of the CSRSS.EXE process), it is unclear 
whether a BSoD can also be triggered via the OpenType format.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without 
a broadly available patch, then the bug report will automatically become 
visible to the public.

Original issue reported on code.google.com by mjurc...@google.com on 18 Nov 2014 at 11:57

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by mjurc...@google.com on 4 Dec 2014 at 4:37

GoogleCodeExporter commented 8 years ago

Original comment by mjurc...@google.com on 11 Dec 2014 at 10:17

GoogleCodeExporter commented 8 years ago

Original comment by mjurc...@google.com on 24 Mar 2015 at 10:06

GoogleCodeExporter commented 8 years ago

Original comment by cev...@google.com on 1 Apr 2015 at 12:11

GoogleCodeExporter commented 8 years ago

Original comment by mjurc...@google.com on 20 Apr 2015 at 2:07

GoogleCodeExporter commented 8 years ago

Original comment by mjurc...@google.com on 12 Jun 2015 at 4:02