This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 800585 - (CVE-2012-1129) CVE-2012-1129 freetype: heap off-by-one buffer underflow in Type42 parser t42_parse_sfnts() (#35602)
CVE-2012-1129 freetype: heap off-by-one buffer underflow in Type42 parser t42...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20120223,reported=2...
: Security
Depends On:
Blocks: 800639
  Show dependency treegraph
 
Reported: 2012-03-06 13:48 EST by Jan Lieskovsky
Modified: 2016-01-26 08:24 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-15 08:28:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2012-03-06 13:48:09 EST
An out-of heap-based buffer read flaw was found in the way Type42 font parser of the FreeType font rendering engine performed parsing of certain special font name table (SFNT) strings. A remote attacker could provide a specially-crafted font file, which once opened in an application linked against FreeType would lead to that application crash.

Upstream bug report:
[1] https://savannah.nongnu.org/bugs/?35602

Upstream patch:
[2] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=82365c0dead99dd119d9e7117cf4f36ce1d1cbe1
Comment 1 Kurt Seifried 2012-03-06 15:48:49 EST
Added CVE as per http://www.openwall.com/lists/oss-security/2012/03/06/16
Comment 2 Jan Lieskovsky 2012-03-07 08:59:42 EST
This issue affects the versions of the freetype package, as shipped with Red Hat Enterprise Linux 5 and 6.

--

This issue affects the versions of the freetype package, as shipped with Fedora release of 15 and 16.
Comment 5 Tomas Hoger 2012-03-15 08:28:18 EDT
This bug is not a security problem.  Affected code is the following code from src/type42/t42parse.c :

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/type42/t42parse.c?id=0b1c0c6b#n610

 610     /* A string can have a trailing zero byte for padding.  Ignore it. */
 611     if ( string_buf[string_size - 1] == 0 && ( string_size % 2 == 1 ) )
 612       string_size--;

Here problem occurs when string_size == 0.  In that case string_buf[string_size - 1] reads one byte right before the beginning of the heap-based string_buf[] buffer.  Such one byte buffer underflow can only lead to program crash when string_buf[] starts at the memory page boundary and the previous page is not mapped.  However, that can not happen with the current glibc malloc() implementation.  A memory address returned to a program by malloc() function has additional malloc header located right before it.  Hence string_buf[string_size - 1] reads part of that header and can not access unmapped memory.

This bug can be detected by memory usage checkers as valgrind or AddressSanitizer, but does not lead to crash during the normal use.

The value read from the malloc header has no impact on whether the "if" expression is evaluated as true or falls.  The second part of the "if" expression is: ( string_size % 2 == 1 ) which evaluates to false when string_size == 0.  Hence string_size is not decremented and remains 0.

The code immediately following is:

 614     if ( !string_size )
 615     {
 616       FT_ERROR(( "t42_parse_sfnts: invalid string\n" ));
 617       error = T42_Err_Invalid_File_Format;
 618       goto Fail;
 619     }

which causes the font file to be rejected as invalid.

Statement:

This bug is not a security issue. For detailed explanation, refer to: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-1129#c5

Note You need to log in before you can comment on or make changes to this bug.