|Summary:||CVE-2012-1134 freetype: limited heap buffer overflow in Type1 parser T1_Get_Private_Dict() (#35608)|
|Product:||[Other] Security Response||Reporter:||Jan Lieskovsky <jlieskov>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||behdad, fonts-bugs, jrusnack, kevin, mkasik|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-24 21:02:23 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||806266, 806267, 806268, 806269, 806270, 806271, 889398|
Description Jan Lieskovsky 2012-03-06 18:52:09 UTC
An out-of heap-based buffer write flaw was found in the way Type1 font parser of the FreeType font rendering engine retrieved private dictionar information for certain Type1 fonts. 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, or, potentially, arbitrary code execution with the privileges of the user running the application. Upstream bug report:  https://savannah.nongnu.org/bugs/?35608 Upstream patch:  http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=d9577add645c8c05460c7d60ad486c021394b82e Acknowledgements: Red Hat would like to thank Mateusz Jurczyk of the Google Security Team for reporting this issue.
Comment 1 Kurt Seifried 2012-03-06 20:52:52 UTC
Added CVE as per http://www.openwall.com/lists/oss-security/2012/03/06/16
Comment 2 Jan Lieskovsky 2012-03-15 15:23:59 UTC
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 7 Tomas Hoger 2012-03-16 16:43:11 UTC
The flaw here is in the T1_Get_Private_Dict() function. It does not check that private_dict (array of FT_Byte / unsigned char) has at least size of 4 before overwriting first 4 characters with ' ' (space). There are two possible cases in the function. One is that private_dict is allocated in the function using the size of less than 4. That case is not an issue, as the minimum chunk glibc malloc can allocate has 12 (on 32bit) or 24 (on 64bit) usable bytes. Hence the overflow would only overwrite memory that can be used by an application and does not lead to crash. This overflow can be detected by memory allocation checking tools as valgrind or AddressSanitizer, as was demonstrated in the upstream bug report. There is another possible case - private_dict may use part of the existing base_dict. In that case, it may be possible for overflow to write out of the usable memory, but the overflow is limited to 3 space characters.