The "transient array" specified in the "Type 2 Charstring format" specs [1] but also available in Type1 fonts [2] (originally for the purpose of facilitating Multiple Master fonts) is allocated dynamically only if the CoolType interpreter encounters an instruction which requires the presence of the array, such as "get" or "store".

While allocating the array, however, the routine does not automatically clear the contents of the newly created buffer. If a reading PostScript instruction is then used to access an item in the array that has not been previously initialized, it is possible to leak data from the transient array into other structures (such as the operand stack) and further use it e.g. as a parameter of the rendered font shapes. The possibility of such scenario is even mentioned in the [1] specification:

"If *get* is executed prior to *put* for /i/ during execution of the current charstring, the value returned is undefined."

The instructions which make it possible to create an uninitialized allocation are as follows:

1) escape + callothersubr + storewv
2) escape + callothersubr + put(2)
3) escape + put
4) escape + callothersubr + get
5) escape + get
6) escape + load
7) escape + store

However, the only ones that can be used to read uninitialized memory are:

1) escape + callothersubr + get and escape + get: load a 32-bit value to the operand stack.
2) escape + load: loads a 32-bit value into the "Registry object" (documented in "The Type 2 Charstring Format, 5 May 1998").

The bug is reproducible with Type1 and OTF fonts. In case of Type1, the length of the transient array (and thus the size of the heap allocation) can be controlled by a "/lenBuildCharArray" dictionary item up to 65535, while in OTF the transient array is always 32 elements long (see the "Appendix B: Type 2 Charstring Implementation Limits" section of [1]).

Contrary to an analogous condition in the Windows Kernel ATMFD.DLL library, the severity of the issue in Adobe Reader CoolType is considered low. We are not aware of any way the uninitialized data could be propagated back to a PDF JS script in order to defeat exploit mitigations such as ASLR (worst case, it would just be displayed on the user's screen); however, if HTML5 canvas-like support was ever added to the Acrobat JavaScript language, the condition would immediately become exploitable.

Adobe Reader 11.0.10 is confirmed to be affected, but we expect all prior versions of the software to be prone to the bug, too. Due to minimal severity of the issue, we have not developed a proof of concept.

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.

References:
[1] "The Type 2 Charstring Format, Technical Note #5177, 16 March 2000", http://partners.adobe.com/public/developer/en/font/5177.Type2.pdf
[2] "The Compact Font Format Specification, Technical Note #5176, Version 1.0, 18 March 1998", http://www-cdf.fnal.gov/offline/PostScript/5176.CFF.pdf