Bug 678563 (CVE-2011-0064) - CVE-2011-0064 pango: missing memory reallocation failure checking in hb_buffer_ensure
Summary: CVE-2011-0064 pango: missing memory reallocation failure checking in hb_buffe...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-0064
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 679693 679694 681378
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-18 12:43 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-30 18:50:17 UTC


Attachments (Terms of Use)
Patch ported to pango (6.14 KB, patch)
2011-02-23 09:18 UTC, Tomas Hoger
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0309 normal SHIPPED_LIVE Critical: pango security update 2011-03-01 23:43:37 UTC

Description Jan Lieskovsky 2011-02-18 12:43:08 UTC
It was discovered that pango did not check for memory reallocation failures in hb_buffer_ensure() function.  This could trigger a NULL pointer dereference in hb_buffer_add_glyph(), where possibly untrusted input is used as an index used for accessing members of the incorrectly reallocated array, resulting in the use of NULL address as the base array address.  This can result in application crash or, possibly, code execution.

It was demonstrated that it's possible to trigger this flaw in Firefox via a specially crafted web page.

Mozilla bug report (currently not public):
https://bugzilla.mozilla.org/show_bug.cgi?id=606997

Fix in the harfbuzz git:
http://cgit.freedesktop.org/harfbuzz/commit/?id=a6a79df5fe2e

Acknowledgements:

Red Hat would like to thank Mozilla Security Team for reporting this issue.

Comment 1 Jan Lieskovsky 2011-02-18 13:07:47 UTC
This issue affects the versions of the pango package, as shipped with
Red Hat Enterprise Linux 3, 4, 5, and 6.

This issue affects the versions of the evolution28-pango package, as
shipped with Red Hat Enterprise Linux 4.

--

This issue affects the versions of the pango package, as shipped with
Fedora release of 13 and 14.

Comment 7 Tomas Hoger 2011-02-23 08:57:47 UTC
(In reply to comment #1)
> This issue affects the versions of the pango package, as shipped with
> Red Hat Enterprise Linux 3, 4, 5, and 6.
> 
> This issue affects the versions of the evolution28-pango package, as
> shipped with Red Hat Enterprise Linux 4.

This initial assessment was incorrect.  The issue only affects pango version in Red Hat Enterprise Linux 6.  Upstream dropped realloc failure checking code in this commit:
  http://git.gnome.org/browse/pango/commit/?id=336bb320

Comment 9 Tomas Hoger 2011-02-23 09:18:29 UTC
Created attachment 480386 [details]
Patch ported to pango

(In reply to comment #0)
> Upstream patch:
> [2] http://cgit.freedesktop.org/harfbuzz/commit/?id=a6a79df5fe2e

Port of this harfbuzz patch to pango, by Karl Tomlinson.

Comment 10 Tomas Hoger 2011-02-28 19:38:05 UTC
Additional patch (in the harfbuzz git) to protect against possible integer overflow in hb_buffer_ensure:
  http://cgit.freedesktop.org/harfbuzz/commit/?id=b5dd44e24669

Comment 11 Tomas Hoger 2011-03-01 10:10:56 UTC
(In reply to comment #10)
> Additional patch (in the harfbuzz git) to protect against possible integer
> overflow in hb_buffer_ensure:
>   http://cgit.freedesktop.org/harfbuzz/commit/?id=b5dd44e24669

Further review of the pango code confirmed that the overflow is not possible in the current versions.

In most hb_buffer_ensure calls, the requested buffer size is only 1 larger than the current number of items in the buffer (and hence at most current capacity + 1).  _hb_buffer_add_output_glyphs is the only place that may request extension larger than 1 (num_out argument).  Sequence::apply is the only place that may call that function with num_out greater than 1.  It passes substitute.len value as num_out argument, which is of unsigned short type and hence 0xffff at max.

Due to that, the loop adjusting new_allocated will not run more than once when current buffer size is large enough to possibly trigger realloc overflow after the new_allocated value increase.  On 32bit platforms, that would require current buffer size of at least 0x8888884 items, which means total memory allocation that already exceeds 2^32 memory size limit and hence is impossible.

The overflow can never happen on 64bit platforms (new_allocated * sizeof(...) is evaluated as size_t expression).

Thanks to Karl Tomlinson for the review and feedback.

Comment 12 Vincent Danen 2011-03-01 23:34:12 UTC
This is public now via:

https://build.opensuse.org/request/show/63070

Comment 13 Vincent Danen 2011-03-01 23:35:14 UTC
Created pango tracking bugs for this issue

Affects: fedora-all [bug 681378]

Comment 14 errata-xmlrpc 2011-03-01 23:43:43 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0309 https://rhn.redhat.com/errata/RHSA-2011-0309.html

Comment 15 Huzaifa S. Sidhpurwala 2011-09-09 07:33:05 UTC
In all the versions of qt shipped with RHEL, in the embedded harfbuzz code,
hb_buffer_ensure / otl_buffer_ensure returned an error and hb_buffer_add_glyph
/ otl_buffer_add_glyph had a check for the error.

Hence it was not vulnerable to the realloc failure.

Statement:

This issue did not affect the versions of qt shipped with Red Hat Enterprise Linux 4, 5 and 6.


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