Re: Opentype font file causes Windows to restart.

[Kaspar Brand <ot () velox ch>]

[Since my first attempt yesterday was not approved by the BugTraq
moderator, I'm trying it again, this time in a slightly different format
and CC'ing vulnwatch, too.]

The problem is due to "incorrect" data in the "CFF" table of this font -
for details, please see the attached message I sent to the OpenType
mailing list (http://www.topica.com/lists/opentype - note that I have
omitted the attachment to this message, which was Andrew's original
BugTraq posting).

This specific flavor of an OpenType font (CFF outlines, i.e.
"PostScript" data) is only supported natively by Windows 2000 and later.
For previous Windows versions, you need ATM (Adobe Type Manager) to
display such a font. Please note that the crash only occurs when trying
to render the "o" character (that's what fontview.exe tries to do, of
course).

As far as the creation of an embedded font for IE (.eot, embedded
OpenType) is concerned, I'm not sure if it's possible to trigger the bug
this way. When installing the "restarter" font and listing the fonts
available for embedding in WEFT, Microsoft's Web Embedding Fonts Tool
(the only publicly available tool I know of to create such fonts),
OpenType fonts with CFF outline data do not appear in the list of
available fonts. I suppose WEFT is currently limited to embed OpenType
fonts with TrueType outlines ("glyf" table) or plain PostScript Type 1
fonts (.pfb file suffix). The .eot format is not documented, as far as I
know, so creating such a font manually would probably require quite some
experimenting, and even then the question remains if IE would actually
be able to deal with this font format and display the characters.

Kaspar




> --- Begin Message ---
>
>
> From: Kaspar Brand <ot () velox ch>
>
> Date: Wed, 08 Jan 2003 10:33:06 +0100
>
> This was recently posted to BugTraq (a mailing list about computer
> security vulnerabilities, for those who don't know).
>
> Further inspection of the font file shows that the problem is in the CFF
> table - or more exactly, within the "o" character. Disassembling the
> font with Just's excellent TTX (http://fonttools.sourceforge.net)
> produces the following result for the "o" character:
>
>
>           <CharString name="o">
>             10 290 rmoveto
>             6 -1 7 1 2 -1 -1 -1 -1 -4 1 -4 1 -3 1 -5 1 -3 1 -5 1 -3 1 -4
> 1 -1 1 1 1 4 1 2 1 5 1 2 1 4 1 5 -1 5 -1 2 -1 2 -1 1 14 -1 -1 -7 1 -5 1
> -4 1 -5 1 -3 1 -4 1 -4 2 2 1 4 1 4 1 3 1 5 1 4 1 4 1 6 -1 1 10 -1 -1 -2
> -1 -1 -1 -5 -1 -2 -1 -4 -1 -3 -1 -4 -1 -3 -1 -3 -1 -4 -1 -3 -1 -4 -1 -3
> -1 -3 -1 -1 -8 2 -1 3 -1 5 -1 3 -1 4 -1 3 -1 4 -2 -2 -1 -4 -1 -3 -1 -4
> -1 -3 -1 -4 -1 -3 -1 -1 -8 1 -1 4 -1 3 -1 4 -1 3 -1 4 -1 3 -1 3 -1 4 -1
> 3 -1 4 -1 3 -1 4 -1 2 -1 1 -1 1 hlineto
>             69 hmoveto
>             8 -1 28 -9 -1 2 -1 1 -3 1 -17 -1 -1 -13 14 2 1 1 1 -12 -2 2
> -1 1 -13 -16 20 1 1 1 1 1 1 2 1 2 1 -8 -1 -4 -37 1 1 1 1 43 -2 2 hlineto
>             223 hmoveto
>             16 -1 4 -1 2 -10 1 -3 -2 3 -1 1 -1 1 -1 1 -1 1 -2 1 -2 1 -11
> -1 -2 -1 -2 -1 -1 -1 -1 -1 -1 -1 -1 -2 -1 -2 -1 -7 -1 -2 1 -6 1 -3 1 -1
> 1 -2 1 -1 1 -1 1 -1 1 -1 2 -1 3 -1 4 1 3 1 1 1 1 1 1 3 1 6 -1 2 -2 1 -2
> 1 7 -1 1 1 2 -1 1 1 6 -1 -1 -1 -1 -2 -1 -17 -4 2 -1 2 -2 -1 -1 -1 -1 -1
> -2 -1 -2 -1 -4 -1 -7 1 -4 1 -3 1 -2 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 2
> -1 2 -1 3 -1 14 1 3 1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 2 1 2 1 3 1
> hlineto
>
> [... some more hmoveto/hlineto stuff deleted ...]
>
>             endchar
>           </CharString>
>
>
> Some simple experiments modifying this Charstring and reassembling the
> font with TTX showed that the crash is caused by the arguments to the
> hlineto operator. The Type 2 charstring specification
> (http://partners.adobe.com/asn/developer/pdfs/tn/5177.Type2.pdf) defines
> an implementation limit of 48 for the argument stack (Appendix B, p.33)
> - but in some cases, the number of arguments to the hlineto operator in
> this particular Charstring clearly exceed this limit.
>
> In the end, this apparently leads to a page fault (i.e. a "blue screen")
> in ATMFD.DLL (the Type1/CFF font driver) - which shouldn't happen in any
> case, of course. I guess the folks at Adobe need to fix this.
>
> BTW, checking the font with CFFChecker from the OpenType FDK gives a
> "Type 2 stack overflow" for this character (which is not really
> surprising, is it?).
>
> Kaspar
>
>
>
>
>
>
>
> --- End Message ---