search

secretsquirrel / google-security-research

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

FreeType 2.5.3 Mac FOND resource parsing out-of-bounds read from stack #155

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In the freetype/src/base/ftmac.c file used exclusively to process Mac font 
files, the following code operating on FOND resources is present (function 
"parse_fond"):

433:      unsigned short  string_count;
434:      char            ps_name[256];
435:      unsigned char*  names[64];
...
439:      string_count = EndianS16_BtoN( *(short*)(p) );
...
464:          unsigned char*  suffixes = names[style->indexes[face_index] - 1];
465:
466:
467:          for ( i = 1; i <= suffixes[0]; i++ )
468:          {
469:            unsigned char*  s;
470:            size_t          j = suffixes[i] - 1;
471:
472:
473:            if ( j < string_count && ( s = names[j] ) != NULL )
474:            {
475:              size_t  s_len = (size_t)s[0];
476:
477:
478:              if ( s_len != 0 && ps_name_len + s_len < sizeof ( ps_name ) )
479:              {
480:                ft_memcpy( ps_name + ps_name_len, s + 1, s_len );
481:                ps_name_len += s_len;
482:                ps_name[ps_name_len] = 0;
483:              }
484:            }
485:          }

Note that the "names" array is 64 entry long, while the "string_count" variable 
stores a 16-bit controlled value. In line 473, the value of "j" (which is a 
controlled 8-bit value) is only checked against string_count but not against 64 
(ARRAYSIZE(names)) before being used as an index into names[]. Therefore, it is 
possible to cause an out-of-bounds read in the "s = names[j]" expression, with 
j ranging between 64 .. 254 and -1. Further on, the invalid pointer can be 
further used to obtain a part of the PostScript font name and copy it into 
"ps_name" in line 480. This can lead to Denial of Service through library 
crash, or potentially memory disclosure, if the font name can be propagated 
back to the attacker.

The bug was identified through manual source code review, thus a proof of 
concept sample is not available at the time of this writing.

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

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

Original comment by mjurc...@google.com on 5 Nov 2014 at 3:11

GoogleCodeExporter commented 9 years ago 
Fixed in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=18a8f0d994336
9449bc4de92d411c78fb08d616c.

Original comment by mjurc...@google.com on 26 Nov 2014 at 11:22

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:05

GoogleCodeExporter commented 9 years ago

Original comment by mjurc...@google.com on 20 Apr 2015 at 2:04