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.
