GNOME Bugzilla – Bug 639882
Heap corruption in font parsing with FreeType2 backend
Last modified: 2011-03-19 18:12:41 UTC
As reported by Dan Rosenberg to Ubuntu in: https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/696616 When used with FreeType2 as a backend, Pango is vulnerable to heap corruption when rendering malformed fonts. The vulnerability occurs in pango_ft2_font_render_box_glyph() in pango/pangoft2-render.c. A buffer is malloc'd with size box->bitmap.rows * box->bitmap.pitch. Subsequently, 0xff is written at offsets into this buffer without checking that these offsets fall within the buffer's boundaries, leading to heap corruption. I tested this against Lucid (Pango 1.28.0) and upstream (Pango 1.28.3). I've attached a fuzzed version of the FreeSerif TrueType font ("crash.ttf") that can be used to reproduce this corruption as follows, using the test-mixed.txt file included in the pango-view directory of the source tree (also attached): # cp /usr/share/fonts/truetype/freefont/FreeSerif.ttf /usr/share/fonts/truetype/freefont/FreeSerif.ttf.bak # cp crash.ttf /usr/share/fonts/truetype/freefont/FreeSerif.ttf # pango-view --backend=ft2 --font=FreeSerif test-mixed.txt *** glibc detected *** pango-view: malloc(): memory corruption: 0x000000000116cfa0 *** ======= Backtrace: ========= ...
Bugzilla won't allow larger files to be attached, so here are links to the attachments from Launchpad: https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/696616/+attachment/1781981/+files/crash.ttf https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/696616/+attachment/1781982/+files/test-mixed.txt
Can you patch it to use g_malloc_n?
I've spent some time investigating this. The code in question seems to go pretty far back, hitting the exploit on some version looks tricky though. Behdad, does something using Pango have to use the PangoFT2FontMap type, or can Pango load FT2 fonts without explicitly asking for it?
Josh, the only uses of PangoFT2FontMap I can think of are older versions of GIMP and Inkscape. It's NOT used by any version of GTK+ or Firefox.
I see a couple of errors in this code. I'm not familiar enough with it to know how to properly fix it though. Looking at version 1.28.3 in pangoft2-render.c In the testcase pango_ft2_font_render_box_glyph() gets called with a width of 663 and height of 20. If you look at line 126, we end up with a buffer of size (height * height), or 400 with the testcase. On line 133, we have a for loop that uses width as the upper bound. So we end up writing 0xff well past our 400 byte buffer (up to around 264 bytes past the end of the buffer). I'm not sure if the answer is to fix that loop, or allocate a bigger buffer. On line 144, we set offset2 to (width - 2 - j), so if we make it this far, we're going to be writing 0xff well beyond the buffer. The for loop on line 145 seems to stay within bounds (presuming a sane offset2 variable). On line 159, we have a similar issue as above. We're using the width variable to calculate our offset. I'm not sure what's right, but whatever fix is used, integer overflow protection should probably also be added to the g_malloc0 call.
Created attachment 179002 [details] [review] Untested patch Please test.
With the above patch applied, pango-view no longer crashes for me. I've not done any other testing with respect to ensuring it doesn't break any other fonts.
Behdad: should this go in? :-) Just wondering whether I can take the patch for stable distros...
Yes. Committing.
Committed.
Could this be also committed to 1.28 branch? Thanks
This will also add a dep on glib-2.24 due: http://library.gnome.org/devel/glib/unstable/glib-Memory-Allocation.html#g-malloc0-n