An out-of heap-based buffer read flaw was found in the way FreeType font rendering engine performed: 1) adding of properties, 2) parsing of properties, 3) checking if particular property is an atom for Glyph bitmap distribution format (BDF) fonts. A remote attacker could provide a specially-crafted BDF font file, which once processed in an application linked against FreeType would lead to that application crash. Upstream bug reports: [1] https://savannah.nongnu.org/bugs/?35597 [2] https://savannah.nongnu.org/bugs/?35598 Upstream patch: [3] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=320d4976d1d010b5abe9d61a7423d8ca06bc34df
CVE-2012-1126 FreeType 2.4.8 Out-of heap-based buffer read by parsing, adding properties in BDF CVE-2012-1127 FreeType 2.4.8 Out-of heap-based buffer read by parsing glyph information and bitmaps for BDF fonts CVE-2012-1128 FreeType 2.4.8 NULL pointer dereference by moving zone2 pointer point for certain TrueType font CVE-2012-1129 FreeType 2.4.8 Out-of heap-based buffer read when parsing certain SFNT strings by Type42 font parser CVE-2012-1130 FreeType 2.4.8 Out-of heap-based buffer read by loading properties of PCF fonts CVE-2012-1131 FreeType 2.4.8 freetype (64-bit specific): Out-of heap-based buffer read by attempt to record current cell into the cell table CVE-2012-1132 FreeType 2.4.8 Out-of heap-based buffer read flaw in Type1 font loader by parsing font dictionary entries CVE-2012-1133 FreeType 2.4.8 Out-of heap-based buffer write by parsing BDF glyph information and bitmaps CVE-2012-1134 FreeType 2.4.8 Out-of heap-based buffer write in Type1 font parser by retrieving font's private dictionary CVE-2012-1135 FreeType 2.4.8 Out-of heap-based buffer read in TrueType bytecode interpreter by executing NPUSHB and NPUSHW instructions CVE-2012-1136 FreeType 2.4.8 Out-of heap-based buffer write by parsing BDF glyph and bitmaps information with missing ENCODING field Sorry guys, not sure if I missed this before or I beat the ML Reference in detail: http://www.openwall.com/lists/oss-security/2012/03/06/13 CVE-2012-1137 FreeType 2.4.8 Out-of heap-based buffer read by parsing BDF font header CVE-2012-1138 FreeType 2.4.8 Out-of heap-based buffer read in the TrueType bytecode interpreter by executing the MIRP instruction CVE-2012-1139 FreeType 2.4.8 Array index error, leading to out-of stack based buffer read by parsing BDF font glyph information CVE-2012-1140 FreeType 2.4.8 Out-of heap-based buffer read by conversion of PostScript font objects CVE-2012-1141 FreeType 2.4.8 Out-of heap-based buffer read flaw by conversion of an ASCII string into a signed short integer by processing BDF fonts CVE-2012-1142 FreeType 2.4.8 Out-of heap-based buffer write by retrieval of advance values for glyph outlines CVE-2012-1143 FreeType 2.4.8 Integer divide by zero by performing arithmetic computations for certain fonts CVE-2012-1144 FreeType 2.4.8 Out-of heap-based buffer write in the TrueType bytecode interpreter by moving zone2 pointer point
*** Bug 407533 has been marked as a duplicate of this bug. ***
*freetype-2.4.9 (10 Mar 2012) 10 Mar 2012; Ryan Hill <dirtyepic@gentoo.org> -freetype-2.4.7.ebuild, +freetype-2.4.9.ebuild: Version bump for CVE-2012-1126, CVE-2012-1127, CVE-2012-1128, CVE-2012-1129, CVE-2012-1130, CVE-2012-1131, CVE-2012-1132, CVE-2012-1133, CVE-2012-1134, CVE-2012-1135, CVE-2012-1136, CVE-2012-1137, CVE-2012-1138, CVE-2012-1139, CVE-2012-1140, CVE-2012-1141, CVE-2012-1142, CVE-2012-1143, and CVE-2012-1144 (bug #407533). You should probably upgrade. Stop using autotools-utils.eclass (bug #392099). Remove old.
Where did the static-libs use flag go in 2.4.9? splashutils needs this so I can upgrade.
Resync your tree.
Thanks much. Arches, please test and mark stable: =media-libs/freetype-2.4.9 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
x86 stable
ppc64 done
amd64 stable
ppc done
Stable for HPPA.
(In reply to comment #11) > Stable for HPPA. Please don't break the portage tree. * Digest verification failed: * /usr/portage/media-libs/freetype/freetype-2.4.9.ebuild * Reason: Filesize does not match recorded size * Got: 3836 * Expected: 3840 This is now in latest portage snapshot for 24 hours.
alpha/arm/ia64/m68k/s390/sh/sparc stable
Thanks, everyone. These could result in RCE, so re-rating as B2 and filing GLSA request.
This issue was resolved and addressed in GLSA 201204-04 at http://security.gentoo.org/glsa/glsa-201204-04.xml by GLSA coordinator Sean Amoss (ackle).
