Next message: Maurycy Prodeus: "BitKeeper remote shell command execution/local vulnerability"
[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
attached mail follows:
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
This archive was generated by hypermail 2b30
: Wed Jan 15 2003 - 14:30:54 PST