search

codenote / google-security-research

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

FreeType 2.5.3 Mac font parsing heap-based buffer overflow due to multiple integer overflows #153

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In the freetype/src/base/ftobjs.c file, we can find multiple auxiliary 
functions for handling uncommon or exotic font formats. One such function is 
"Mac_Read_POST_Resource", which heavily operates on user-supplied data:

1586:    FT_Long    len;
1587:    FT_Long    pfb_len, pfb_pos, pfb_lenpos;
1588:    FT_Long    rlen, temp;
...
1596:    /* Find the length of all the POST resources, concatenated.  Assume */
1597:    /* worst case (each resource in its own section).                   */
1598:    pfb_len = 0;
1599:    for ( i = 0; i < resource_cnt; ++i )
1600:    {
1601:      error = FT_Stream_Seek( stream, offsets[i] );
1602:      if ( error )
1603:        goto Exit;
1604:      if ( FT_READ_LONG( temp ) )
1605:        goto Exit;
1606:      pfb_len += temp + 6;
1607:    }
1608:
1609:    if ( FT_ALLOC( pfb_data, (FT_Long)pfb_len + 2 ) )
1610:      goto Exit;
1611:
1612:    pfb_data[0] = 0x80;
1613:    pfb_data[1] = 1;            /* Ascii section */
1614:    pfb_data[2] = 0;            /* 4-byte length, fill in later */
1615:    pfb_data[3] = 0;
1616:    pfb_data[4] = 0;
1617:    pfb_data[5] = 0;
1618:    pfb_pos     = 6;
1619:    pfb_lenpos  = 2;

In the above code, there are multiple instances of integer handling problems:

1. There is an integer overflow in the "temp + 6" expression in line 1606.
2. There is an integer overflow in the "pfb_len += temp + 6" expression, 
overflowing the "pfb_len" variable in line 1606.
3. There is an integer overflow in the "(FT_Long)pfb_len + 2" expression in 
line 1609.

All of the above problems can be used on 32-bit builds to allocate fewer bytes 
for the "pfb_data" buffer than is actually required and therefore trigger a 
heap-based buffer overflow. This is illustrated by the attached example 
proof-of-concept sample (1.ttf), which causes the allocation to be only 1-byte 
long, while more bytes are written to the buffer in lines 1613-1619 (and later 
on in the function), resulting in the following AddressSanitizer output:

=================================================================
==10832== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf5c006d1 
at pc 0xf5f97664 bp 0xfffa9cd8 sp 0xfffa9ccc
WRITE of size 1 at 0xf5c006d1 thread T0
    #0 0xf5f97663 in Mac_Read_POST_Resource freetype2/src/base/ftobjs.c:1613
    #1 0xf5f9843f in IsMacResource freetype2/src/base/ftobjs.c:1811
    #2 0xf5f98ad9 in IsMacBinary freetype2/src/base/ftobjs.c:1888
    #3 0xf5f990a8 in load_mac_face freetype2/src/base/ftobjs.c:2003
    #4 0xf5f999fe in FT_Open_Face freetype2/src/base/ftobjs.c:2165
    #5 0xf5f964ff in FT_New_Face freetype2/src/base/ftobjs.c:1254
    #6 0x804b5a8 in get_face ft2demos-2.5.3/src/ftbench.c:705
    #7 0x804bc64 in main ft2demos-2.5.3/src/ftbench.c:924
0xf5c006d1 is located 0 bytes to the right of 1-byte region 
[0xf5c006d0,0xf5c006d1)
allocated by thread T0 here:
    #0 0xf61a3854 (/usr/lib32/libasan.so.0+0x16854)
    #1 0xf5f8adf7 in ft_alloc freetype2/builds/unix/ftsystem.c:102
    #2 0xf5fb2d74 in ft_mem_qalloc freetype2/src/base/ftutil.c:76
    #3 0xf5fb2bde in ft_mem_alloc freetype2/src/base/ftutil.c:55
    #4 0xf5f975de in Mac_Read_POST_Resource freetype2/src/base/ftobjs.c:1609
    #5 0xf5f9843f in IsMacResource freetype2/src/base/ftobjs.c:1811
    #6 0xf5f98ad9 in IsMacBinary freetype2/src/base/ftobjs.c:1888
    #7 0xf5f990a8 in load_mac_face freetype2/src/base/ftobjs.c:2003
    #8 0xf5f999fe in FT_Open_Face freetype2/src/base/ftobjs.c:2165
    #9 0xf5f964ff 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: heap-buffer-overflow 
freetype2/src/base/ftobjs.c:1613 Mac_Read_POST_Resource
Shadow bytes around the buggy address:
  0x3eb80080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb80090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb800a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb800b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb800c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x3eb800d0: fa fa fa fa fa fa fa fa fa fa[01]fa fa fa fd fd
  0x3eb800e0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x3eb800f0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 00
  0x3eb80100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb80110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3eb80120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==10832== ABORTING

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

Attachments:

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

Original comment by mjurc...@google.com on 5 Nov 2014 at 1:47

GoogleCodeExporter commented 9 years ago 
Fixed in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=240c94a185cd8
dae7d03059abec8a5662c35ecd3, but then the (2) problem was re-introduced again 
in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=453316792fee9
12cfced48e9e270e9eb19892e64.

Problems (1) and (3) are properly fixed, in the meanwhile I have pinged the 
developer to submit another patch.

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

GoogleCodeExporter commented 9 years ago 
This is finally fixed in 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=cd4a5a26e591d
01494567df9dec7f72d59551f6e.

Original comment by mjurc...@google.com on 26 Nov 2014 at 8:39

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