krishnateja / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

FreeType 2.5.3 sbits parsing potential out-of-bounds read due to integer overflow #167

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
In freetype/src/sfnt/ttsbit.c, the following code responsible for parsing 
embedded bitmaps (so-called "sbits") is found:

323:    FT_ULong         strike_index_array;
324:    FT_ULong         strike_index_count;
...
377:      decoder->strike_index_array = FT_NEXT_ULONG( p );
378:      p                          += 4;
379:      decoder->strike_index_count = FT_NEXT_ULONG( p );
380:      p                          += 34;
381:      decoder->bit_depth          = *p;
382:
383:      if ( decoder->strike_index_array > face->sbit_table_size             
||
384:           decoder->strike_index_array + 8 * decoder->strike_index_count >
385:             face->sbit_table_size                                         )
386:        error = FT_THROW( Invalid_File_Format );

Note that the "strike_index_count" field is a fully controlled 32-bit variable, 
so if it is set to >= 0x20000000 in the input file, the "8 * 
decoder->strike_index_count" expression overflows on 32-bit builds of FreeType. 
Furthermore, the overall "decoder->strike_index_array + 8 * 
decoder->strike_index_count" expression can also overflow for smaller values of 
"strike_index_count", depending on "strike_index_array".

This can be used to bypass the sanity check and later trigger an out-of-bounds 
read in the "tt_sbit_decoder_load_image" function:

1059:    FT_Byte*  p          = decoder->eblc_base + 
decoder->strike_index_array;
1060:    FT_Byte*  p_limit    = decoder->eblc_limit;
1061:    FT_ULong  num_ranges = decoder->strike_index_count;
...
1066:    for ( ; num_ranges > 0; num_ranges-- )
1067:    {
1068:      start = FT_NEXT_USHORT( p );
1069:      end   = FT_NEXT_USHORT( p );
1070:
1071:      if ( glyph_index >= start && glyph_index <= end )
1072:        goto FoundRange;
1073:
1074:      p += 4;  /* ignore index offset */
1075:    }

Specifically, the "start" and "end" variables can be loaded from outside of the 
allocated buffer, if no corresponding glyph range is found inside of it. This 
can be used to crash the program using FreeType, or potentially disclose 
information about the contents of adjacent heap memory chunks.

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

GoogleCodeExporter commented 9 years ago
Reported in https://savannah.nongnu.org/bugs/?43591.

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

GoogleCodeExporter commented 9 years ago
Fixed in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=257c270bd25e1
5890190a28a1456e7623bba4439.

Original comment by mjurc...@google.com on 13 Nov 2014 at 8:17

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

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