bugThe FreeType Project - Bugs: bug #43535, FreeType 2.5.3 BDF parsing...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43535: FreeType 2.5.3 BDF parsing potential heap pointer disclosure

Submitter:  Mateusz Jurczyk <j00ru>
Submitted:  Wed 05 Nov 2014 12:14:17 PM UTC
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.5.4
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Fri 07 Nov 2014 09:17:48 AM UTC, comment #2: 

I discovered the problem during a manual audit of the code, similarly to all other issues reported so far. :-)

Mateusz Jurczyk <j00ru>
Project Member
Fri 07 Nov 2014 08:40:25 AM UTC, comment #1: 

Fixed in git, thanks.  I'm curious: How did you find this issue?

Werner LEMBERG <wl>
Project Administrator
Wed 05 Nov 2014 12:14:17 PM UTC, original submission:  

In the internal "_bdf_add_property" function defined in freetype/src/bdf/bdflib.c, the following code can be found:

1429:    if ( ft_strncmp( name, "DEFAULT_CHAR", 12 ) == 0 )
1430:      font->default_char = fp->value.l;
1431:    else if ( ft_strncmp( name, "FONT_ASCENT", 11 ) == 0 )
1432:      font->font_ascent = fp->value.l;
1433:    else if ( ft_strncmp( name, "FONT_DESCENT", 12 ) == 0 )
1434:      font->font_descent = fp->value.l;

While the function itself is responsible for adding new entries to an internal database of properties associated with the input font, it also checks for several specific properties and uses them to initialize some structure fields (default_char, font_ascent, font_descent). The code assumes that the type of those properties is either BDF_CARDINAL or BDF_INTEGER, which is correct, because they are hard-coded in the same source file:

 92:    { (char *)"DEFAULT_CHAR",            BDF_CARDINAL, 1, { 0 } },
...
101:    { (char *)"FONT_ASCENT",             BDF_INTEGER,  1, { 0 } },
102:    { (char *)"FONT_DESCENT",            BDF_INTEGER,  1, { 0 } },

On the other hand, all user-specified properties are of type BDF_ATOM, which uses the "atom" part of the "value" union instead of "l" or "ul":

107:  /* This structure represents a particular property of a font. */
108:  /* There are a set of defaults and each font has their own.   */
109:  typedef struct  bdf_property_t_
110:  {
111:    char*  name;         /* Name of the property.   */
112:    int    format;       /* Format of the property. */
113:    int    builtin;      /* A builtin property.     */
114:    union
115:    {
116:      char*          atom;
117:      long           l;
118:      unsigned long  ul;
119:
120:    } value;             /* Value of the property.  */
121:
122:  } bdf_property_t;

Due to the fact that the strncmp() function is used to recognize the special property names instead of strcmp(), longer names starting with the required strings can be used to pass the checks, too. For example, if a BDF font with the following line is supplied to FreeType:

DEFAULT_CHAR_SOME_IRRELEVANT_SUFFIX ARGUMENT

Then "font->default_char" will be set to a heap pointer pointing at the user-controlled "ARGUMENT" string. The three values (and especially ascent and descent) control how text is displayed on the screen, so in case of a scenario where it is possible to read pixels back (e.g. a web browser), this could be used to disclose an internal pointer and potentially defeat ASLR.

Attached is a font which triggers the described behavior. However, since the bug doesn't result in a hard crash, it can be best observed if a debug printf() is added after initialization of the default_char/font_ascent/font_descent fields in freetype/src/bdf/bdflib.c:1429-1434. Example output:

$ ./ftbench /path/to/poc.bdf
...
Leaked pointer: 0x265fa10
Leaked pointer: 0x26617b0
Leaked pointer: 0x2661890

Mateusz Jurczyk <j00ru>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #32372:  poc.bdf added by j00ru (28KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by j00ru (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-11-07 wl StatusNone Fixed
        PrivacyPrivate Public
        Assigned toNone wl
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.5.4
    2014-11-05 j00ru Attached File- Added poc.bdf, #32372

    Back to the top


    Powered by Savane 3.9