FreeType 2.5.3 PCF parsing NULL pointer dereference due to 32-bit integer overflow

[GoogleCodeExporter]

In freetype/src/pcf/pcfread.c, the following code is found:

402:    FT_ULong           nprops, i;
403:    FT_ULong           format, size;
...
406:    FT_ULong           string_size;
...
410:    error = pcf_seek_to_table_type( stream,
411:                                    face->toc.tables,
412:                                    face->toc.count,
413:                                    PCF_PROPERTIES,
414:                                    &format,
415:                                    &size );
...
485:      (void)FT_READ_ULONG_LE( string_size );
...
491:    /* rough estimate */
492:    if ( string_size > size - nprops * PCF_PROPERTY_SIZE )
493:    {
494:      error = FT_THROW( Invalid_Table );
495:      goto Bail;
496:    }
497:
498:    /* allocate one more byte so that we have a final null byte */
499:    if ( FT_NEW_ARRAY( strings, string_size + 1 ) )
500:      goto Bail;
501:
502:    error = FT_Stream_Read( stream, (FT_Byte*)strings, string_size );

Since the "size", "nprops" and "string_size" variables are fully controlled in 
the input file, we can set them such that size=0xffffffff, nprops=0 and 
string_size=0xffffffff. In this case, the "string_size + 1" expression in line 
499 will overflow to 0. This should typically result in a valid heap pointer 
returned by the standard C allocator and consequently a buffer overflow in line 
502. However, the FreeType allocator (which internally boils down to the 
"ft_mem_qrealloc" function) returns NULL on size=0 (freetype/src/base/ftutil.c):

133:    else if ( new_count == 0 || item_size == 0 )
134:    {
135:      ft_mem_free( memory, block );
136:      block = NULL;
137:    }

As a result, the "FT_Stream_Read" function will attempt to read an enormously 
large number of bytes into a NULL pointer, thus crashing the application:

ASAN:SIGSEGV
=================================================================
==17208== ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 
0xf6156a8c sp 0xffae82f4 bp 0xffae8748 T0)
AddressSanitizer can not provide additional info.
    #0 0xf6156a8b (/usr/lib32/libasan.so.0+0x1ba8b)
    #1 0xf6148c0b (/usr/lib32/libasan.so.0+0xdc0b)
    #2 0xf5f5bafb in FT_Stream_ReadAt freetype2/src/base/ftstream.c:145
    #3 0xf5f5b8a1 in FT_Stream_Read freetype2/src/base/ftstream.c:114
    #4 0xf603577f in pcf_get_properties freetype2/src/pcf/pcfread.c:502
    #5 0xf6038917 in pcf_load_font freetype2/src/pcf/pcfread.c:1108
    #6 0xf603a826 in PCF_Face_Init freetype2/src/pcf/pcfdrivr.c:274
    #7 0xf5f441d7 in open_face freetype2/src/base/ftobjs.c:1191
    #8 0xf5f477ea in FT_Open_Face freetype2/src/base/ftobjs.c:2123
    #9 0xf5f444ff in FT_New_Face freetype2/src/base/ftobjs.c:1254
    #10 0x804b5a8 in get_face ft2demos-2.5.3/src/ftbench.c:705
    #11 0x804bc64 in main ft2demos-2.5.3/src/ftbench.c:924
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==17208== ABORTING

The attached "poc.pcf" sample can be used to reproduce the behavior.

Original issue reported on code.google.com by mjurc...@google.com on 6 Nov 2014 at 10:58

Attachments:

• poc.pcf

[GoogleCodeExporter]

Reported in https://savannah.nongnu.org/bugs/?43547.

Original comment by mjurc...@google.com on 6 Nov 2014 at 10:59

[GoogleCodeExporter]

Fixed in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=0e2f5d518c60e
2978f26400d110eff178fa7e3c3.

Original comment by mjurc...@google.com on 7 Nov 2014 at 9:15

• Changed state: Fixed

[GoogleCodeExporter]

All fixed by upstream:

FreeType 2.5.5

2014-12-30
FreeType 2.5.5 has been released. This is a minor bug fix release: All users of 
PCF fonts should update, since version 2.5.4 introduced a bug that prevented 
reading of such font files if not compressed.

FreeType 2.5.4

2014-12-06
FreeType 2.5.4 has been released. All users should upgrade due to another fix 
for vulnerability CVE-2014-2240 in the CFF driver. The library also contains a 
new round of patches for better protection against malformed fonts.

The main new feature, which is also one of the targets mentioned in the pledgie 
roadmap below, is auto-hinting support for Devanagari and Telugu, two widely 
used Indic scripts. A more detailed description of the remaining changes and 
fixes can be found here.

Original comment by cev...@google.com on 26 Jan 2015 at 5:27

• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

Original comment by mjurc...@google.com on 25 Feb 2015 at 2:05

• Added labels: CVE-2014-9671