Bug 691867 - Buffer Overflow in xps_true_callback_glyph_name() using Verdana font
Summary: Buffer Overflow in xps_true_callback_glyph_name() using Verdana font
Status: RESOLVED FIXED
Alias: None
Product: GhostXPS
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: PC Windows Vista
: P4 normal
Assignee: Tor Andersson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-05 18:23 UTC by Martin Lercher
Modified: 2011-02-03 19:44 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
xps file to reproduce the buffer overflow (343.56 KB, application/vnd.ms-xpsdocument)
2011-01-05 18:23 UTC, Martin Lercher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Lercher 2011-01-05 18:23:27 UTC
Created attachment 7088 [details]
xps file to reproduce the buffer overflow

Applies to ...\ghostpdl-9.00\xps\xpsttf.c

The original lines (line #179)

  char buf[16];
  sprintf(buf, "glyph%d", (int)glyph);

overflow the 16 bytes string buffer when glyph is 0xC0000000, which is a long negative integer number in %d format.


Proposed change: 
change %d to %#X

    /* Format 1.0 (mac encoding) is a simple table see the TT spec.
     * We don't implement this because we don't see it in practice.
     * Format 2.5 is deprecated.
     * Format 3.0 means that there is no post data in the font file.
     * We see this a lot but can't do much about it.
     * The only format we support is 2.0.
     */
    if ( format != 0x20000 )
    {
        /* Invent a name if we don't know the table format. */
        char buf[16];
>>>	sprintf(buf, "glyph%#X", (int)glyph);
        pstr->data = (byte*)buf;
        pstr->size = strlen((char*)pstr->data);
        return 0;
    }

Possible side effect: 
A different subsystem relies on the specified formatted glyph name, eg glyph32 which would now be glyph0X20 instead.

Sample command line to reproduce:
xps\debugobj\gxps.exe -sDEVICE=pdfwrite -sOutputFile=test.pdf -dNOPAUSE tools\ieprint.xps
Comment 1 Martin Lercher 2011-01-05 18:27:27 UTC
An other possible side effect:
%#X may fail on different platforms/int sizes as well.
Comment 2 Tor Andersson 2011-02-03 19:44:49 UTC
I have increased the buffer size to fit large (and negative) numbers.