Bug 678563 (CVE-2011-0064)

Summary: CVE-2011-0064 pango: missing memory reallocation failure checking in hb_buffer_ensure
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: mbarnes, mclasen, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-30 18:50:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 679693, 679694, 681378    
Bug Blocks:    
Attachments:
Description Flags
Patch ported to pango none

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.